[Sammelthread] ZNAS (ZFSNAS) Chezmoi

[toscdesign]

Für mich fehlt noch Rechtevergabe auf Ordner-Ebene und lock/unlock von verschlüsselten Pools/Datasets. Dann ist mein Use-Case komplett abgebildet

Mit Keys geht das schon, für Passphrase habe ich mein eigenes Script geschrieben.
Kann ich hier anhängen

 

[Shihatsu]

Was ich gern noch hätte sind Backups von ZFSNAS1 zu ZFSNAS2

 

[toscdesign]

@Shihatsu
Das hatte ich damit gemeint:

Remote Snapshot Replication mit Pull verfahren.

 

[Shihatsu]

@Shihatsu
Das hatte ich damit gemeint:

Aaaaa wer lesen kann ist klar im Vorteil, streicht meinen Wunsch

 

[you]

Mit Keys geht das schon, für Passphrase habe ich mein eigenes Script geschrieben.
Kann ich hier anhängen

Key kenne und nutze ich. Gibt es den unlock Button schon? Über Konsole kann ich das auch, wäre aber schön, wenn auch das über UI geht.

Ich werde erst mal nen Backup-Server damit betreiben und schauen, wie der sich so macht. Aktuell schaut es gut aus.

 

[toscdesign]

Für Keys ist das schon lange in der GUI

 

[you]

Yepp ... typo. Ich wollte LOCK schreiben, also wieder sperren ... sorry

 

[asm@s24]

v6.3.25 ... Link ZNASes

 

[toscdesign]

Leider für meine Meinung nicht nutzbar da:

Select from a drop-down any interlink server as a target for zfs push on snapshot
• Select Interlink push directly on dataset or zvol, browser the destinations and remote pool and launch in background


Push Methode und damit kein Ransomware Schutz. Pull Methode wird sicherlich noch nachgeliefert.


Unterschied erklärt:
- Push Methode:
Das Quellgerät hat die Zugangsdaten zum Zielgerät und schickt die Daten. Hat jemand oder eine Ransomware Zugriff auf das Quellgerät kann auch das Zielgerät kompromittiert werden.
- Pull Methode:
Das Quellgerät hat keinerlei Zugangsdaten zum Zielgerät. Das Zielgerät hat die Zugangsdaten zum Quellgerät und zieht von dort die Daten. Ist das Quellgerät kompromittiert, kann der Angreifer aber nicht auf das Zielgerät zugreifen.

 

[asm@s24]

Hat jemand oder eine Ransomware Zugriff auf das Quellgerät kann auch das Zielgerät kompromittiert werden.

Schon richtig, aber doch etwas theoretisch. In der Praxis wird "jemand" sowieso Zugang zu Deinem kompletten Netzwerk und allen Geräten erlangen ... 😰

 

[toscdesign]

Nein

Edit:
Das Zielgerät ist in einem anderen Netzwerk, mit eigener Firewall. Das Netzwerk des Quellgerätes hat keinerlei Zugriff auf dieses.

 

[asm@s24]

Nein

Lol.

Ehrlicherweise muß ich sagen, hab ich bisher noch nie Erfahrung mit Ransomwareattacken gehabt seit es Internet gibt.

Was wäre denn der Vorteil von ZFS-Replikation gegenüber einem "richtigen" Backup? Bei mir läuft ja alles unter PVE, also mach ich Backups mit PBS. Allein wegen der irren Deduplizierung find ich das praktisch.

Nehmen wir mal an, ein PC fängt sich was ein und verschlüsselt terabyteweise SMB-Shares auf einem ZNAS. Dann würde der neue terabytegroße Snapshot - idealerweise - von einem anderen ZNAS in einem anderen Netz via Pull rübergeholt. Also ... was ist da jetzt sicherer dran?

Der vorige unverschlüsselte Snapshot ist ja auf dem Quellnas auch noch da.

 

[toscdesign]

Dann würde der neue terabytegroße Snapshot - idealerweise - von einem anderen ZNAS in einem anderen Netz via Pull rübergeholt. Also ... was ist da jetzt sicherer dran?

Die alten Snapshots bleiben auf dem Ziel Gerät dabei unangetastet erhalten, sofern das richtig eingestellt ist.

Edit:
Die Pull Methode ist z.B. die empfohlene Methode von TrueNAS.

 

[asm@s24]

Die alten Snapshots bleiben auf dem Ziel Gerät dabei unangetastet erhalten

Auf dem Quellgerät bleiben sie ja auch erhalten. Sinnvollerweise hat man ja 'ne Kette, 1x nachts für die letzten 7 Tage z.B.

Eigentlich braucht man eher so was wie'n Alarm. "Achtung, neuster Snapshot hat 7 TB. Faktor 100 gegenüber den letzen 7."
Jegliche automatische Replikation, ob nun pull oder push, ist in dem Fall eh unsinnig. Man muß erst mal schaun, was da los ist.

 

[BobbyD]

Instant Update funktioniert bei mir nicht. Vielleicht hat ja jemand hier ne Idee, woran das liegen könnte.

Changelog v6.3.25

• Fix on Instant Update Button. On some fast system, the service was starting too fast and the binary swap may had issue

 

[BobbyD]

Weiß jemand, ob das hier Proxmox spezifisch ist (zfs_arc_max)?

If your root file system is ZFS, you must update your initramfs every time this value changes:

# update-initramfs -u -k all

You must reboot to activate these changes.

Wenn das generell gilt, dann wäre das für mich wohl eher ein Grund, auf eine ZFS-Install als Boot zu verzichten.

 

[you]

Which value?
EDIT: Jetzt wirds klarer. Das ist ja doof.

 

[toscdesign]

Auf dem Quellgerät bleiben sie ja auch erhalten.

Bis der Eindringling diese löscht

 

[besterino]

Dafür braucht der Angreifer root und wenn er das hat, ist in der Regel eh „Gute Nacht“.

 

[toscdesign]

@besterino
Deshalb ja Snapshot Replikation Pull Verfahren.
Denn da kann der Angreifer gerne root auf dem Quellgerät haben. Damit kann er auf dem Zielgerät (Backup) keinen Schaden anrichten.

Die ZFS-Snapshot-Replikation im Pull-Verfahren (auch "Pull-Backup" genannt) ist eine sehr sichere Methode zur Datensicherung, da der Sicherungsserver (Backup-Ziel) aktiv die Daten vom Produktionsserver (Quelle) abruft. Im Gegensatz zum Push-Verfahren hat der Produktionsserver keinen direkten Schreibzugriff auf das Backup-Ziel, was die Sicherheit bei Ransomware-Angriffen deutlich erhöht.

Hauptsicherheitsmerkmale des Pull-Verfahrens:
Keine Schreibrechte für die Quelle: Wird der Quellserver kompromittiert, können die Backups auf dem Zielserver nicht ohne Weiteres gelöscht oder verschlüsselt werden.
Inkrementelle Backups: Es werden nur geänderte Blöcke zwischen Snapshots übertragen, was effizient ist.
Sicherer Transport: Die Übertragung erfolgt typischerweise über verschlüsseltes SSH.
Schutz vor Datenkorruption: ZFS verwendet End-to-End-Prüfsummen, um stille Datenkorruption bei der Replikation zu erkennen.

 

[Luckysh0t]

Wenn man da nun noch die Logik von unseren veeam hardendrepos nachbauen möchte, könnte man die Backup datasets danach mit einem dedizierten User auf read only stellen.

 

[toscdesign]

Wenn ich root Rechte habe, kann ich die trotzdem löschen.

 

[asm@s24]

Denn da kann der Angreifer gerne root auf dem Quellgerät haben. Damit kann er auf dem Zielgerät (Backup) keinen Schaden anrichten.

Also wir reden doch hier von ZNAS Interlink ... Und wenn der auf dem Quell-ZNAS root hat, wie sollte er auf den Ziel-ZNAS nicht alles löschen können? Selbst wenn die via Pull die Daten bekämen? Über die Oberfläche auf der Quelle kann der dann alles spülen. 🤷‍♂️

 

[toscdesign]

Du verstehst es nicht.

Die ZFS-Snapshot-Replikation im Pull-Verfahren (auch "Pull-Backup" genannt) ist eine sehr sichere Methode zur Datensicherung, da der Sicherungsserver (Backup-Ziel) aktiv die Daten vom Produktionsserver (Quelle) abruft. Im Gegensatz zum Push-Verfahren hat der Produktionsserver keinen direkten Schreibzugriff auf das Backup-Ziel, was die Sicherheit bei Ransomware-Angriffen deutlich erhöht.

Weiß nicht wie man das noch einfacher erklären soll

 

[asm@s24]

Du verstehst es nicht.

Du ja auch nicht. 😄
ZNAS hat kein Pullverfahren.

Das ist Wünsch-Dir-Was.
Falls das noch kommt, dann über ihr Interlink, da bin ich sicher.
Und dann sind alle Geräte über die gemeinsame Oberfläche bedienbar und löschbar.

Weiß nicht wie man das noch einfacher erklären soll

Ich auch nicht.

 

[toscdesign]

ZNAS hat kein Pullverfahren.

Das sage ich doch die ganze Zeit 😭

 

[asm@s24]

Ja ich auch. Und ich wollte nur drauf hinweisen, daß es wohl so wie von Dir erhofft nicht kommt.

We implemented only push of replication for now. To tell you the truth, we are still arguing how we should implement the pull part and make it easy. We have a feature coming where you can “link” multiple zfsnas together, the top left hostname then become a drop-down and you can switch between your system, and because they know each other that open some simplicity when you want to push/pull between system.

 

[you]

Ich denke, sie arbeiten dran README.MD

Beitrag automatisch zusammengeführt: Vor 55 Minuten

Mein Verständnis ist, dass es am Ende egal sein kann, ob ab Snapshot X ein Pool kompromitiert ist, da ich ja auf ein Snapshot VOR X zurückgehen kann. Voraussetzung: Ich halte genug alte Snapshots vor.

 

[asm@s24]

"Simple", also via Interlink, ist ungleich "sicher".

Denn da kann der Angreifer gerne root auf dem Quellgerät haben. Damit kann er auf dem Zielgerät (Backup) keinen Schaden anrichten.

Gilt eben dann nicht.

Aber vielleicht lassen die sich am Ende doch noch überzeugen.
Das ist ja auch das extrem Gute, die hören auf Nutzer.

 

[toscdesign]

TrueNAS hatte das Pull Verfahren ja auch simpel in der GUI implementiert. Vielleicht sollte man einfach deren Variante einfach übernehmen?