Anzeige:
Ergebnis 1 bis 14 von 14

Thema: Rückwirkungsfreiheit durch Rsync

  1. #1
    Registrierter Benutzer
    Registriert seit
    May 2017
    Beiträge
    3

    Rückwirkungsfreiheit durch Rsync

    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

  2. #2
    Universaldilletant Avatar von fork
    Registriert seit
    Dec 2001
    Ort
    Frankfurt/Main
    Beiträge
    1.175
    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.
    Geändert von fork (02.05.17 um 13:55 Uhr)

  3. #3
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    Zitat Zitat von Torsten84 Beitrag anzeigen
    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



    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...
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

  4. #4
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    Zitat Zitat von fork Beitrag anzeigen
    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.
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

  5. #5
    Universaldilletant Avatar von fork
    Registriert seit
    Dec 2001
    Ort
    Frankfurt/Main
    Beiträge
    1.175
    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.
    Geändert von fork (02.05.17 um 15:05 Uhr)

  6. #6
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    Zitat Zitat von fork Beitrag anzeigen
    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?
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

  7. #7
    Registrierter Benutzer
    Registriert seit
    May 2017
    Beiträge
    3
    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

  8. #8
    Registrierter Benutzer
    Registriert seit
    Jun 2003
    Beiträge
    578
    Als Denkanstoss noch rsync als Daemon
    gruss sys;-)

  9. #9
    Registrierter Benutzer
    Registriert seit
    May 2017
    Beiträge
    3
    Hallo zusammen,

    hier die Antworten auf eure Fragen.

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

    Zitat Zitat von florian0285 Beitrag anzeigen
    rsync mit ssh oder nur rsync?
    Ohne ssh

    Zitat Zitat von florian0285 Beitrag anzeigen
    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.


    Zitat Zitat von florian0285 Beitrag anzeigen
    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.


    Zitat Zitat von florian0285 Beitrag anzeigen
    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.

    Zitat Zitat von florian0285 Beitrag anzeigen
    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.

    Zitat Zitat von fork Beitrag anzeigen
    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.

    Zitat Zitat von fork Beitrag anzeigen
    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.

    Zitat Zitat von florian0285 Beitrag anzeigen
    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.

    Zitat Zitat von florian0285 Beitrag anzeigen
    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
    Geändert von Torsten84 (03.05.17 um 12:07 Uhr)

  10. #10
    Universaldilletant Avatar von fork
    Registriert seit
    Dec 2001
    Ort
    Frankfurt/Main
    Beiträge
    1.175
    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.
    Geändert von fork (03.05.17 um 11:22 Uhr)

  11. #11
    Newbie and practicing Avatar von Newbie314
    Registriert seit
    Mar 2007
    Beiträge
    7.639
    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.
    Bei Konsolenausgaben / Fehlermeldungen bitte immer Code Tags verwenden: [code] -Text- [/code]
    "Überzeugungen sind gefährlichere Feinde der Wahrheit als Lügen" (H. Lesch)

  12. #12
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    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.


    Zitat Zitat von Newbie314 Beitrag anzeigen
    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/IT...05/m05063.html

    Die eingesetzten Verschlüsselungsverfahren u. a. AES, RSA und DSA sind ebenfalls anerkannt. Lediglich die Zertifizierung für nationale VS fehlt.
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

  13. #13
    Newbie and practicing Avatar von Newbie314
    Registriert seit
    Mar 2007
    Beiträge
    7.639
    Lediglich die Zertifizierung für nationale VS fehlt
    Exakt der Grund warum ich es als Beispiel nahm.
    Bei Konsolenausgaben / Fehlermeldungen bitte immer Code Tags verwenden: [code] -Text- [/code]
    "Überzeugungen sind gefährlichere Feinde der Wahrheit als Lügen" (H. Lesch)

  14. #14
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    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]
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

Ähnliche Themen

  1. Antworten: 12
    Letzter Beitrag: 07.10.08, 15:43
  2. rSync - Muss rSync immer beidseitig installiert sein?
    Von confusion im Forum Linux als Server
    Antworten: 35
    Letzter Beitrag: 08.02.08, 11:57
  3. jede Nacht Rechnerabsturz durch rsync
    Von swen1 im Forum Linux als Server
    Antworten: 4
    Letzter Beitrag: 10.01.06, 18:31
  4. Regelmäßiges Kopieren durch rsync!?
    Von micha97 im Forum Sicherheit
    Antworten: 3
    Letzter Beitrag: 23.09.03, 16:20
  5. rsync durch Proxy
    Von snoopy99 im Forum System installieren und konfigurieren
    Antworten: 0
    Letzter Beitrag: 24.10.02, 10:39

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •