Meinung: Berechtigungen: Aus Sicherheitsgründen schreiben, aber nicht lesen?

7

Ich habe eine Reihe verbundener Systeme und möchte einen separaten Server für inkrementelle und vollständige Sicherungen einrichten.

Um auch den Verlust aller Systeme / Backups im Falle einer Kompromittierung zu verhindern, denke ich darüber nach, dies zu einer Drop-Box-Angelegenheit zu machen, bei der auf jedem System, auf das Backups übertragen werden, eine Nur-Schreib-Freigabe bereitgestellt wird.

Ich beabsichtige, dass im Falle eines Angriffs das Backup über eine neu erstellte schreibgeschützte Freigabe dem betroffenen System zugänglich gemacht oder auf dieses übertragen und dann von dort wiederhergestellt werden kann - aber auf das System selbst kann nicht zugegriffen werden.

Einer unserer Konkurrenten hat kürzlich sein gesamtes Geschäft verloren, weil sogar seine Backups verbunden waren - sodass sie nichts wiederherstellen konnten.

In geeigneten Abständen werde ich auch vollständige Backups herunterladen.

Bitte stecke Löcher in meinen Plan.

Vielen Dank.

— edooze
quelle

4

"Einer unserer Konkurrenten hat kürzlich sein gesamtes Geschäft verloren, weil sogar seine Backups verbunden waren. Sie hatten also nichts, von dem sie wiederherstellen konnten." Nur Lesen schützt Sie nicht, wenn jemand von irgendwoher darauf schreiben kann. Sie sind 1 davon > {backupfile}entfernt, es zu löschen. Ich würde verhindern WRITE auf Dateien präsentieren auf dem Datenträger. Verwenden Sie zeitbasierte Verzeichnisse und markieren Sie sie mit dem unveränderlichen Bit: Ich sage, warum -jeder außer root auf diese Dateien zugreifen darf.

— Rinzwind

2

Persönlich würde ich die Freigabe als Lese- / Schreibzugriff belassen, aber einige Maschinen einrichten, um Snapshots davon zu erstellen, entweder in regelmäßigen Abständen oder nachdem der Client signalisiert, dass er alle seine Daten an ihn weitergegeben hat. Bedeutet die Verwendung eines Copy-on-Write-Dateisystems auf dem Sicherungsserver. Persönlich würde ich mich für BSD, zfs und ECC-fähige Hardware entscheiden, da ich bereits einmal Backups (aber zum Glück nicht die entsprechenden Lebensdaten) durch btrfs-Beschädigung verloren habe, möglicherweise aufgrund eines schlechten Speichers. Ich würde auch rsync anstelle der Freigabe verwenden, da ich denke, dass es effizienter sein könnte. Plus --fake-superbedeutet sauberere Berechtigungen für die Backups.

— MvG

19

Bitte stecke Löcher in meinen Plan.

Sicher. Nur das Entfernen von Lesevorgängen hindert Sie nicht an Problemen. Jeder Änderungsversuch erfordert Schreibberechtigungen. Ein Angreifer kann die Datei dann immer noch leer schreiben (er muss nur wissen, wo sich die Datei befindet).

Warum nicht irgendetwas auf dieser Festplatte in Bezug auf Backups sperren, außer das Anhängen neuer Daten?

Mögliches Setup:

/backups/20160911/backup.tar.gz
/backups/20160912/backup.tar.gz
/backups/20160913/backup.tar.gz

Erstellen Sie ein Skript, das dies tut

chattr -R +a /backups/
chattr -R +i /backups/*.tar.gz

+ibedeutet "unveränderlich"; Mit diesen Dateien oder Verzeichnissen kann nichts gemacht werden. Nicht einmal root kann es ändern (dazu gehört das Entfernen, Bearbeiten, Schreiben und Hinzufügen neuer Dateien. Alles). Sogar root muss dies (mit -i) entfernen, bevor root etwas mit diesen Dateien tun kann.

+abedeutet "anhängen"; Gleiche Regeln wie -imit 1 Ausnahme. Es ist niemandem gestattet, Änderungen an der Datei oder dem Verzeichnis vorzunehmen, außer sie zu ergänzen . Und noch einmal: Sogar root muss dies (mit a -a) entfernen, bevor die Datei oder das Verzeichnis geändert werden kann, wenn durch die Änderung keine Inhalte daran angehängt werden.

(Oben ist möglicherweise eine Optimierung erforderlich. 1 große Sicherungsdatei ist möglicherweise nicht der beste Ansatz. Etwas mit Unterverzeichnissen und Dateien ist möglicherweise besser. Dies würde eine Anpassung dieser beiden Zeilen erfordern: Führen Sie dies beispielsweise NUR für alte Verzeichnisse durch und tun Sie dies "Heute" manuell, wenn die Sicherung abgeschlossen ist. Dann wird dies

chattr -R +i /backups/{not_today}
chattr -R +a /backups/{today}

Lassen Sie dieses Skript in regelmäßigen Abständen ausführen. Wenn also irgendwann jemand etwas ändert, werden /backups/die Berechtigungen für alle Sicherungen zurückgesetzt.

Verzeichnisse und Dateien können zu "Heute" hinzugefügt werden. Nach Abschluss der Sicherung können Sie das + i manuell hinzufügen. Erstellen Sie ein gutes Administratorkennwort, und niemand außer dem Administrator wird diese Dateien berühren. Je.

Übrigens: Erwägen Sie auch, Backups online zu speichern. Wir haben unsere Backups in mehreren Google-Instanzen (wir haben 3 Live-Systeme auf 3 Kontinenten, die die Daten gemeinsam nutzen und jeweils eine Fallback-Instanz auf einem anderen Kontinent erstellen, und diese teilen sich jeweils ein Backup-System).

— Rinzwind
quelle

Ich bin kein Profi unter Linux, konnte aber zum Beispiel nicht open / dev / hda1 rooten und die Datei ändern, selbst wenn es das unveränderliche Flag gibt?

5

@Advancid In der Antwort wird bereits erwähnt, dass sie das unveränderliche Bit entfernen können, wenn sie so bestimmt sind. Der Schutz hier erhebt keinen Anspruch auf Sicherheit gegen einen Angreifer mit Root-Zugriff.

— IMSoP

@Advancid ja, root kann alles. Dies ist auch der EINZIGE Weg, um dies zu entfernen: root muss dies tun.

— Rinzwind

4

@Advancid Soweit ich das beurteilen kann, gilt der Anwendungsfall, wenn der Sicherungsserver selbst nicht kompromittiert wird, um zu verhindern, dass andere Server (die kompromittiert sind) ihren normalen Zugriff auf den Sicherungsserver verwenden, um die Sicherungen zu zerstören.

— Random832

4

Entfernen Sie die readBerechtigung aus den Dateien oder Verzeichnissen, die Sie nicht lesen möchten.

Die Berechtigungen sind:

u - Owner
g - group
o - others

Deaktivieren Sie das Lesen für alle und das Richtige für alle, die Schreibzugriff haben möchten.

$ chmod -R ugo-r [path]

Das Verzeichnis [Pfad] und alle seine Dateien und Unterverzeichnisse haben dieses Attribut. In diesem Fall die -r(kein Lesezugriff).

— LD James
quelle

1

Es wäre einfacher, das x-Bit aus dem übergeordneten Verzeichnis zu entfernen

— Zanna

@Zanna Ich dachte darüber nach, aber das würde das Kriterium des OP für das Schreiben in die Unterverzeichnisse zunichte machen.

— LD James

Oh ja, du hast Recht :) Es wäre auch einfacher (und ich denke, ich bin diesmal nicht dumm) zu tuna-r

— Zanna

3

Nichts ist so sicher wie getrennte Sicherungen. Laden Sie Ihre Backups auf ein externes Laufwerk herunter und trennen Sie es vom Netzwerk, nachdem Sie das Backup auf das Laufwerk kopiert haben. Holen Sie sich eine Reihe von Laufwerken und drehen Sie sie.

Kaufen Sie beispielsweise 5 1-TB-Laufwerke (Gesamtkosten <300 USD). Weisen Sie 3 davon als tägliche Backups zu. Verbinden Sie jeden Tag eine, kopieren Sie das Backup darauf und trennen Sie die Verbindung. Weisen Sie eine als wöchentliche Sicherung und eine als monatliche Sicherung zu und machen Sie dasselbe.

Bewahren Sie einige Laufwerke im Falle eines Brandes oder Diebstahls an einem zweiten Ort auf.

Dieser Ansatz schützt Sie vor vielen verschiedenen Bedrohungen durch Datenverlust.

Wenn Ihr System ausschließlich serverbasiert ist, verwenden Sie ein Cloud-Äquivalent. Richten Sie einige Server bei verschiedenen Anbietern ein (Amazon, Google, Azure). Stellen Sie täglich eine Verbindung zu einem anderen Server her und senden Sie Ihr Backup auf diesen Server. Trennen Sie dann die Verbindung. Bewahren Sie mehrere Kopien auf, damit Sie nicht über eine gute Kopie sichern.

Aber nichts ist so unhackbar wie eine physische Kopie, die Sie von einem Netzwerk trennen und an einem externen Ort aufbewahren.

— Thoma
quelle