write-only mount?

Jump to last post
sia

sia

gesperrt
Registriert
26 März 2015
Beiträge
5.926
Ort
FFM (NSFW)
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.
 
@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.
 
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.
 
Zuletzt bearbeitet:
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. :)
 
Ich tippe zu langsam...
Kommt aber wohl auch ein wenid darauf an, was da letztendlich nun rauskommen soll, bei der Aktion. ;)
 
  • Thread Starter Thread Starter
  • #7
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 ;)
 
Öhm:
You do not have permission to view link please Anmelden or Registrieren

You do not have permission to view link please Anmelden or Registrieren


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.:p
Auf der anderen Seite hat mich auch noch keiner dafür bezahlt.
 
Bin da nich so tief drin, aber mit CDFS sollte sowas doch machbar sein? Keinen Plan, ob man das auf ne Festplatte bekommt...
 
m6ld8ywqyas Lösung halte ich ebenfalls für sinnvoll. Damit schaltest du den Client als ausführendes Organ und Risikofaktor beim Backup komplett aus.
 
  • Thread Starter Thread Starter
  • #12
Ä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?
 
Unter Linux gibt es doch das Problem von Cryptloggern nicht? (musste sein :p)

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.
 
  • Thread Starter Thread Starter
  • #14
drfuture schrieb:
Unter Linux gibt es doch das Problem von Cryptloggern nicht? (musste sein :p)
Zum Vergrößern anklicken....
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
You do not have permission to view link please Anmelden or Registrieren
oder
You do not have permission to view link please Anmelden or Registrieren
. Bei Windows ist das natürlich an der Tagesordnung, deswegen
You do not have permission to view link please Anmelden or Registrieren
You do not have permission to view link please Anmelden or Registrieren
You do not have permission to view link please Anmelden or Registrieren
You do not have permission to view link please Anmelden or Registrieren
;)

wenn Dateisystem-Rechte ausgehebelt werden schaut die Sache aber so oder so wieder ganz anders aus.
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....
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?
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....
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...
 
Zuletzt bearbeitet:
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 ^^
 
  • Thread Starter Thread Starter
  • #16
You do not have permission to view link please Anmelden or Registrieren
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 :D
 
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.
 
Ganz früher gab es mal ein Standard-Backup-Programm, das im ursprünglichen Sinne nur für Tapes gedacht war. Nannte sich "tar". :cool:

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.
 
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.

Metal_Warrior schrieb:
@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.
Zum Vergrößern anklicken....
Das ist technisch machbar, aber nur in Hardware:
You do not have permission to view link please Anmelden or Registrieren
:D (ein echter Klassiker der Digitaltechnik)
 
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.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben