write-only mount?

[sia]

Hi, kann ich Festplatten so mounten, dass man nur schreiben, aber nicht bearbeiten/lesen kann?

Würde gerne bestimmte Dateien so verstauen, dass man sie nicht mehr bearbeiten kann. chmod 000 ist mir zu unsicher.

 

[Metal_Warrior]

@phre4k:
Ich bin mir gar nicht sicher, ob das überhaupt technisch möglich ist. Üblicherweise muss eine Datei ja zum Schreiben erstmal geöffnet werden, also ein read durchgeführt werden, bevor ein Schreibvorgang stattfinden kann. Insofern glaube ich, du stößt hier tatsächlich an die Grenze des technisch Machbaren.

 

[alter_Bekannter]

Nur neue Dateien per Cronjob kopieren?

Bzw Dateien per Cronjob in ein Verzeichnis moven auf das die Benutzer gar keinen Zugriff haben. Auf dem Weg könntest du diese Einwegaktionen durchführen.

Technisch machbar sind append Aktionen vom Filesystem her ohne Dateien zu lesen, die Frage ist obs dafür Berechtigungen gibt.
Man könnte ja nur lesen vom Index erlauben.

 

[thom53281]

Imho ist das sehr wohl möglich, aber schwierig und ineffektiv. Zudem habe ich das noch nie probiert, also keine Ahnung, wie praxistauglich das ist und ob es überhaupt so funktioniert.

Der Trick besteht darin, die HDD *nicht* zu mounten und sich selbst ein Quasi-Dateisystem auszudenken. dd wird normalerweise dafür benutzt, ganze Images auf HDDs zu schreiben. Es spricht aber eigentlich nichts dagegen, auch einfache Dateien damit auf die HDD zu schreiben. Heißt im Klartext, Du fängst am HDD-Anfang an, eine erste Datei zu schreiben. Du merkst Dir das Offset und lässt dd mit der nächsten Datei am Offset-Startpunkt weiterschreiben. Wenn es sich um verbreitete Dateietypen handelt, kannst Du diese dann später mit Datenrettungssoftware aka Photorec wieder von der HDD lesen. Oder Du merkst Dir, wo welche Datei liegt (Startpunkt+Größe), dann kannst Du sie auch ohne Rettungssoftware wieder lesen.

Das Problem des Bearbeitens löst das aber nicht, Schreibzugriff ist Schreibzugriff. Genauso wäre prinzipiell auch das Lesen möglich. Allerdings ist beides extrem erschwert durch das fehlende Dateisystem.


Wenn Du das, worauf Du letztendlich genau hinaus möchtest, noch etwas genauer bescheibst - evtl. gibt es auch noch eine praxistauglichere Lösung.

 

[alter_Bekannter]

Das ist nur die kompliziertere Variante meines Vorschlags.

 

[thom53281]

Ich tippe zu langsam...
Kommt aber wohl auch ein wenid darauf an, was da letztendlich nun rauskommen soll, bei der Aktion.

 

[sia]

Geht um ein Backup-Cluster, welches nicht von Cryptolocker o.ä. heimgesucht werden soll.

Derzeit ist das mit rsync via SSH und authorized_keys-Beschränkung gelöst (Backup-User darf nur mit rsync schreiben).

Dachte, dass es vielleicht eine simple Lösung gibt, auf die ich einfach nicht gekommen bin (extra Dateisystem a la overlayfs z.B.). Aber anscheinend gibt es die ja nicht

 

[alter_Bekannter]

Öhm:
http://unix.stackexchange.com/questions/22577/write-access-without-read-access
http://superuser.com/questions/586209/write-but-not-read-permission-on-a-file-in-linux

Lassen darauf schließen das es sowas doch schon gibt, sepziell die Erwähnung von Logfiles in dem Kontext beschreibt doch exakt das was ich auch genannt habe als tendenzeill möglich.

Wenn du sowas nicht willst müsstest du sogar "nur" noch was streichen ich hab allerdings noch nie Filesystem Treiber gemoded.
Auf der anderen Seite hat mich auch noch keiner dafür bezahlt.

 

[dexter]

Bin da nich so tief drin, aber mit CDFS sollte sowas doch machbar sein? Keinen Plan, ob man das auf ne Festplatte bekommt...

 

[m6ld8ywqya]

Geht um ein Backup-Cluster, welches nicht von Cryptolocker o.ä. heimgesucht werden soll.

Die Clients vom Server aus sichern und die Backups den Clients nur lesbar zur Verfügung stellen.

 

[musv]

m6ld8ywqyas Lösung halte ich ebenfalls für sinnvoll. Damit schaltest du den Client als ausführendes Organ und Risikofaktor beim Backup komplett aus.

 

[sia]

Äh ja, derzeit wird das schon mit rsnapshot erledigt (also vom Server). War vielleicht etwas missverständlich. Allerdings kann durch eine Sicherheitslücke in rsnapshot oder unbekannte Angriffsvektoren ja trotzdem der ganze Ordner unbrauchbar gemacht werden, wenn der Server selbst Schreibzugriff darauf hat.

Soll ich den Backupserver noch mal von einem anderen Server sichern lassen? Oder vielleicht einen LXC-Container für rsnapshot anlegen und dann ein Skript schreiben, das die Daten verifiziert und dann in einen anderen Ordner kopiert? Wie würde ich das mit dem Skript anstellen? Kopieren oder verschieben, wenn weniger als 50% der Daten komplett geändert wurden? (Cryptolocker verschlüsselt ja alles)

CDFS ist nicht die dümmste Idee, aber wie schreibe ich da rein? Einfach cat nutzen oder muss ich da dann jedes Mal eine CD brennen?

 

[drfuture]

Unter Linux gibt es doch das Problem von Cryptloggern nicht? (musste sein )

wenn Dateisystem-Rechte ausgehebelt werden schaut die Sache aber so oder so wieder ganz anders aus.
Der Server an sich muss ja auch nicht schreiben können - ein Backup-User unter welchem das Backup-Programm läuft sonst niemand.

Die Frage ist dann eh in was du im Zielsystem sicherst da evtl. Datei / Ordner-Rechte mit gebackuped werden müssen?
Somit käme so oder so nur etwas in Frage das die Dateien in einem Backup-Container / Stream hinterlegt inkl. Rechten und der Zugriff auf diese Datei ist nur mir einem Backup-User möglich.

 

[sia]

Unter Linux gibt es doch das Problem von Cryptloggern nicht? (musste sein )

Wer sagt das? Linux ist bei einem gezielten Angriff genauso unsicher oder sicher wie jedes andere Betriebssystem, deswegen diskutieren wir hier ja.

Gab in der Vergangenheit ja beispielsweise Linux.Encoder.1 oder Ransom32. Bei Windows ist das natürlich an der Tagesordnung, deswegen keine gesonderte Meldung wert

wenn Dateisystem-Rechte ausgehebelt werden schaut die Sache aber so oder so wieder ganz anders aus.

Da hast du recht, vielleicht sollte ich einfach auf Backups und das Nichtvorhandensein eines Root-Exploits vertrauen.

Der Server an sich muss ja auch nicht schreiben können - ein Backup-User unter welchem das Backup-Programm läuft sonst niemand.

Na ja, Root kann halt immer schreiben...

Die Frage ist dann eh in was du im Zielsystem sicherst da evtl. Datei / Ordner-Rechte mit gebackuped werden müssen?

Ah, stimmt. Gar nicht dran gedacht – mal schauen, ob das unbedingt notwendig ist. Sind ja hauptsächlich User-Dateien, Webapps etc. werden noch mal gesondert gesichert.

Somit käme so oder so nur etwas in Frage das die Dateien in einem Backup-Container / Stream hinterlegt inkl. Rechten und der Zugriff auf diese Datei ist nur mir einem Backup-User möglich.

Gute Idee! Ich könnte quasi rsnapshot/rsync mit einem User namens backup1:backup starten und danach per Script das Backup chown backup2:backup und chmod 750 setzen. Dann könnte der ursprüngliche Backup-User zwar immer noch auf das Backup zugreifen, allerdings nur lesend. Oder ich mache gleich chmod 550, muss ja eigentlich nie verschoben werden...

 

[drfuture]

Ich habe das nie gesagt - da das ist so allgemeine Netzmeinung *mit Linux wäre das nicht passiert* *g* - Aber schön das wir uns ja einig sind ^^

 

[sia]

@drfuture: man muss ja realistisch sein. Nur, weil es in der freien Wildbahn für Linux 30 verschiedene Malwares und für Windows und OS X 30 Millionen, heißt das nicht, dass es gar keine gibt

EDIT: hängt auch von der Malware-Definition ab. Ich sehe Adware z.B. auch als Malware und da gibt's z.B. für Android (auch Linux) einen Haufen, was sich dann in den Autostart hängt. Beispielsweise die App Premium Wallpapers HD (com.pixign.premiumwallpapers). Das inspiriert mich direkt schon wieder zu einem neuen Thread

EDIT2: ich erinnere mich hiermit mal selbst, wieder BTT zu kommen

 

[Metal_Warrior]

Wenn dus schon so aufziehen willst, wie wäre dann die Variante:

Clients 1-200 werden auf $SERVER gebackupt
$BKPSRV ist ein Raspi mit einer mobilen Festplatte

$BKPSRV hat per SSH Lesezugriff auf die Backup-Daten auf $SERVER und ist per iptables völlig geschottet - nur eine key-authenticated SSH-Verbindung zum $SERVER darf raus, jeglicher anderer Verkehr wird rejected. $BKPSRV zieht sich alle X Stunden ein Backup vom $SERVER, kann das sogar sauber verschlüsseln und gestaffelt organisieren, dass selbst bei einer unbemerkten Infektion nicht sofort die mühsam gesicherten Daten überschrieben werden.

 

[musv]

Ganz früher gab es mal ein Standard-Backup-Programm, das im ursprünglichen Sinne nur für Tapes gedacht war. Nannte sich "tar".

Ich weiß, damit hat man dann Redundanz im Backup. Aber ist das nicht eigentlich der Sinn eines Backups? Also:

Backup-Server zieht sich die zu sichernden Daten vom Client (rsync, nfs, …) und schiebt die direkt in ein tar-Archiv. Du musst Dir dann halt nur 'ne Strategie überlegen, welche Sicherungspunkte (Monat, Woche) du davon aufhebst, um im Schadensfall nicht zuviele aktuelle Daten zu verlieren.

 

[Pleitgengeier]

Geht es dir dabei wirklich darum, auch lesen zu verhindern?
Nicht bearbeiten aber erstellen und lesen ist glaube ich relativ einfach machbar.

Bezüglich Cryptlocker hast du dann aber das Problem, wenn dein Backup-Vorgang dein Backup mit gelocktem überschreibt. Privat sichert man ja normalerweise nicht - wie in Unternehmen üblich - auf Bänder, die dann eingelagert und nie wieder beschrieben werden.

@phre4k:
Ich bin mir gar nicht sicher, ob das überhaupt technisch möglich ist. Üblicherweise muss eine Datei ja zum Schreiben erstmal geöffnet werden, also ein read durchgeführt werden, bevor ein Schreibvorgang stattfinden kann. Insofern glaube ich, du stößt hier tatsächlich an die Grenze des technisch Machbaren.

Das ist technisch machbar, aber nur in Hardware: http://repeater-builder.com/molotora/gontor/25120-bw.pdf (ein echter Klassiker der Digitaltechnik)

 

[virtus]

Die Backups werden doch extern gespeichert, oder? Hast du dort keine Versionsverwaltung?
Selbst wenn ein Trojaner/Virus die Dateien lokal verschlüsselt und diese zum Backupdevice synchronisiert werden, sollte es kein Problem sein, eine ältere Fassung wiederherzustellen.