Backup "relativ" ransomware sicher

[MyPVR]

Ohne das ich mir alle Antworten durchgelesen habe: Ein NAS verstehe ich nicht als Backupsystem. Für mich ist sowas eine externe Festplatte, die nur während des Backups an dem PC hängt (und sonst ausgeschaltet oder im Schrank ist).

 

[coasterblog]

Ein NAS verstehe ich nicht als Backupsystem

Die man auch trennen kann, physikalisch oder durch das OS. Von daher auch nur ein externer Speicher.

Meine ist auch nur am Strom wenn ich sie brauche.

 

[MyPVR]

@coasterblog Neben einer Backup-HDD für meinen PC, habe ich extra eine für das NAS. Wenn ein NAS nicht immer am Netz im Zugriff ist, tut's auch ne einfache USB-HDD. Zumindest meine Meinung...

 

[Giggity]

Man braucht ja kein 2 oder 4 Bay NAS. Als BackupNAS reicht bereits eine DS118 die 1x in der Woche fürs Backup hochfährt.

EDIT: Das kann man dann mit einem Backupprogramm schön automatisieren und muss sich nicht mehr drum kümmern.

 

[coasterblog]

Wenn ein NAS nicht immer am Netz im Zugriff ist, tut's auch ne einfache USB-HDD

Die NAS ist ja wenn verwendet nicht nur für einen Rechner da. Da ist eine externe Platte nicht von Vorteil.
Und sie ist auch keine reine Backuplösung bei mir. Backup Nr 1 sind externe Platten.

 

[Rickmer]

Relativ ransomware sicher und gleichzeitig ohne manuelle Interaktion ist ein extrem schwieriges Thema. Am nächsten dran ist man da dran mit dem Veeam Hardened Repository:

https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository.html?ver=110

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Hier noch ein 'paar Worte' (mit hohem Grad an Expertise) aus dem Veeam R&D Newsletter zu dem Thema:

As more users are adopting V11 Hardened Repositories, I see this question being asked repeatedly: why do we not allow hardened repositories to also carry other backup infrastructure roles? The reason is that our whole paradigm for hardened repo is, so to speak, a designated survivor: something designed to survive the worst of break-ins on everything else in the infrastructure, being the last line of defense for your data. So we didn't look at simply making it harder for random hackers who go around picking on easy targets, just enough to make them move on to the next one. Rather, we wanted to ensure our customers could built a storage appliance that will protect their backups against bad guys with infinite resources AND a reason to target your company specifically. For example, because your shady competitor paid 10M to some powerful hacker group to disrupt your business, calculating that your sales and brand damage from the IT infrastructure being offline for weeks of a complete re-build will result in ten-fold pay-off (which are not unrealistic numbers when talking about companies with 1B annual revenue).

Now, you may ask if it's possible even in theory to design a network-connected system in a way to withstand a targeted attack with 100% guarantee? The answer is no: with enough time and resources anything that is not air-gapped (offline) can be hacked eventually, just because OS and hardware vulnerabilities will never cease to appear. However, we bet on the fact that in case of a tiniest attack surface, the fitting vulnerability will be once-in-a-decade event at best - but attack windows are rarely THAT long, at least in the commercial sector: companies get acquired, go out of business, change their infrastructure, actual backup storage and even their backup solution (unless they use Veeam of course) far more often.

And this is exactly why we designed our hardened repository with reducing the attack surface to a bare minimum in mind. Specifically, the only service running under root privileges implements just a handful of functions, each with just a few lines of code. This makes ensuring that this service is air-tight secure actually doable for our security analysts. Compare that with trying to make sure there are no vulnerabilities in a huge code footprint of a backup proxy or a tape server, which are required to run most of their operations as root and moreover rely on 3rd party components like VDDK or drivers in doing their job – and you'll understand why we don't want you running these on hardened repositories in the first place, providing opportunities for a privilege escalation attack.

Importantly, we can only do as much from our end ensuring minimum possible attack surface. But it is still on you to make sure there are no other network services or remote management interfaces listening on your hardened repository server, and to disable them completely! And whatever decision you make around them, always keep in mind you're ensuring safety and security of your designated survivor – while as they say, only the paranoid survive! So please, think twice before giving any additional opportunities to hackers.

For example, are you contemplating keeping SSH enabled but protected with an MFA solution? Again, not only you'll increase the attack surface with possible bugs in MFA code, but you're also exposing yourself to known MFA attack vectors like SIM swap attack. In fact, these are so easy and common these days that I would recommend disabling SMS/call authentication options in your MFA solution ASAP, in favor of using an authenticator app on a smartphone. Although unfortunately, recent developments show us that bad guys are capable of performing extremely targeted attacks on specific individuals when needed, and completely take over even smartphones supplied by closed-source closed-everything vendors like Apple.

My previous newsletter about V11 hardened repository resulted in quite a few follow-ups, so I wanted to cover some of the top 5 questions/concerns here. Q: If I don't have a spare physical server available, can I run a hardened repository in a VM? A: While there's nothing stopping you from this, it's a terrible idea as anyone who gains control over the hypervisor can destroy data of any VM at a lower level than where immutability protects it. Remember that a hypervisor has full access to the storage its VMs are using, and thus can wipe this storage in no time (way faster than a bad guy with a hammer in a server room). At the same time, virtual infrastructure provides a huge attack surface with all of its user interfaces and APIs – but most of you don't need convincing here because you're the ones who are patching those vulnerabilities every other week. Q: Can Veeam provide a hardened repository in a form of an OVA virtual appliance, as to simplify its deployment and configuration? A: We won't do this even just because it will be perceived as the suggested deployment method, driving most customers to deploy hardened repository in a VM, which makes absolutely no sense from a cyber threat prevention perspective. Having said that, we're planning to make hardened repository much more visible and easier to deploy in V12. Q: Does it make any sense at all to use the immutable backups option on classic, non-hardened repositories (deployed without single-use credentials)? A: While this won't protect your backups against hackers, who will be able to wipe them if they take over the backup server and retrieve stored credentials, it's not completely useless as having your backups immutable still protects them against "good guys". For example, this will prevent their accidental deletion in the following cases: manual deletion of backup files during regular storage management tasks, automatic deletion after an erroneous change of the retention policy, automatic deletion due to a potential data loss bug in Veeam. By the way, V12 will have the dedicated repository type for hardened repositories, so it will be much easier to track repositories with saved credentials. Q: I disabled all remote access interfaces on my hardened backup repository as you suggested. Unfortunately, having SSH Server disabled turned installing Veeam updates into a nightmare as I need to be physically present at the repository server. And for me this means N miles long drive to M different sites each and every time! A: We're already working on addressing this issue with some architecture changes. In future, updating Veeam components on a hardened repository will not require temporarily enabling SSH access, as hardened repository will be able to download and install [signed] update packages by itself. Q: How can I securely monitor my hardened repository hardware with SSH disabled? No visibility into hardware failures opens an opportunity for data loss due to more traditional causes, such as undetected hardware failure. A: Syslog to a central syslog server is a gold standard of monitoring Linux systems. Since you only need to allow an outgoing connection in the hardened repository's firewall for this to work, it will have little impact on hardened repository security. Most hardware vendors also provide their own monitoring agents that you could install locally and configured to send email alerts or SNMP traps, which both likewise only require allowing an outgoing connection only.

Remember my series of posts about a hardened repository last fall where I noted that unlike air-gapped (offline) storage, no network-connected system can provide 100% protection against cyber-attacks because software, OS and hardware vulnerabilities will never cease to be found? And that even with the tiniest attack surface, once in a decade there will be a fitting vulnerability that will allow to take over such systems? Well, the pkexec vulnerability disclosed last week makes a good demonstration of how insane those super rare vulnerabilities can be. This one allows to effortlessly obtain root privileges on ANY existing Linux system so long as you can log into it under any unprivileged account. At which point it's game over because no matter how the particular storage appliance achieves data immutability, there's simply no protection against root. The scary part is that pkexec has been vulnerable since its creation in May 2009. Another way to look at it: that sudoers file was completely optional for the past 12 years, as anyone in the know could just run any command as root. Now tell me how those fancy security workflows requiring multiple approvals before immutable backups can be deleted by remote support actually help, when vulnerabilities like this allow hackers to instantly elevate ANY account to the same God Mode? The possibility of such vulnerabilities is exactly why I suggest disabling all types of remote consoles on hardened repositories leaving physical access to a local console the only option, as this is something hackers can never do. Meanwhile, please install updates patching pkexec on all your Linux systems ASAP. Here's the detailed information about the vulnerability from security researchers who found it > CVE-2021-4034

 

[IBISXI]

Normalerweise verwendet man mehrere Festplatten in Rotation.

@obuda
Ich denke Du überverkomplizierst das alles.

Verwende 2 oder mehrere Datenträger in Rotation um die Daten zu sichern.
(Fesplatten oder SSDs)

Selbst wenn ein Trojaner einen Teil verschlüsselt hätte, ohne dass Du es gemerkt hast, gibt es die Daten noch auf einer anderen Platte.

 

[guzzisti]

Mal von der Ransomware abgesehen, hast Du mit einem NAS, das zwar ausgeschaltet aber zumindest kabelseitig verbunden ist die Gefahr, dass bei einem Blitzeinschlag in der Nähe das Backup auch gegrillt werden kann.

Am sinnvollsten finde ich eine mehrstufige Backupstrategie. Daten die häufigen Änderungen unterliegen automatisch per Software aufs NAS oder "in die Cloud" aka Onlinespeicher - letzteres natürlich nur verschlüsselt. Damit hat man dann auch gleich ne Versionierung der Daten. Zusätzlich dann ein Backup des NAS/der Cloud auf externe Festplatten, die offline im feuerfesten Tresor/Koffer gelagert werden. Da sollte man dann mehrere Festplatten durchrotieren.

Wichtig dabei ist: nicht nur sichern!
Regelmäßig ausprobieren, ob man die Daten auch wiederherstellen kann, insbesondere wenn man sich hier auf "komplexe" Software verläßt, die eventuell ein proprietäres Speicherformat verwendet.

Mein Offline-Backups sind daher ausschließlich Vollbackups auf normalen Dateisystemen. Da kann ich im Notfall einfach eine Platte anschließen und hab die Daten direkt im Zugriff.

 

[NobodysFool]

PC Zugriff auf NAS "Partition 1" geben (lesen + schreiben); PC erstellt Backups auf Partition 1. Dienst auf NAS kopiert Daten 1x täglich von Partition 1 auf "Partition 2". PC hat, wenn überhaupt, nur Leserechte auf Partition 2. Nachdem Daten erfolgreich kopiert wurden, werden die Daten auf Partition 1 gelöscht.

Szenarien:

• Malware verschlüsselt PC und löscht Backups/NAS: Partition 1 wird gelöscht, Partition 2 bleibt erhalten
• Restore eines Backups: im besten Falle gibt es das aktuellste Backup von Partition 1, sonst von Partition 2

Warum so kompliziert? Hin- und hersynchronisieren ist ein unnützer zusätzlicher Schritt. Der PC Benutzer hat auf die NAS-Freigabe mit den Backups entweder nur Leserechte oder gleich gar keine Rechte. Auf dem NAS existiert ein extra angelegter Backup-Benutzer mit Schreib-/Leserechten, der auf dem PC gar nicht erst existiert. Jede vernünftige Backupsoftware kann sich nun mit diesem Backupnutzer auf das NAS einloggen und dir Backups dort ablegen, ohne dass der am PC angemeldete Benutzer (und somit Ransomware) jemals irgendwelche Rechte da drauf haben muss.

Wenn man jetzt noch ein NAS hat das Snapshots bietet, kann man hier noch Netz und doppelten Boden einbauen. Und wenn man dann diese Backups auf dem NAS noch synchronisieren will, dann mit einer externen Platte die man auch woanders lagert.

 

[gymfan]

Backups sind nicht etwas was man mit einer Bastellösung löst. Das Geld was du dir sparst bereust du im Worstcase doppelt und dreifach.

Ich traue meiner robocopy/rsync Lösung zehnmal mehr wie der früher mal genutzten Acrions Lösung. Systemimages muss ich nicht täglich erstellen und wenn, würden diese halt, genauso wie von NPC geschrieben, aufs NAS gelegt (oder gleich vom NAS nach der Erstellung automatisch abgezogen).

Für mich ist das alles besser wie irgendwas, an das ich auch nur denken muss oder für das ich gar eine manuelle Aktion durchführen muss.

Relativ ransomware sicher und gleichzeitig ohne manuelle Interaktion ist ein extrem schwieriges Thema.

Was soll daran schwierig sein, so lange man wenigstens dem OS seines NAS traut und das ganze nicht als professionelle Wissenschaft aufziehen will?

NPC hat die einfache Lösung ja schon gepostet. Das geht sogar mit jedem QNap/Synologie-NAS ohne dass man dort irgeindein Script selber laufen lassen müsste.

Mal von der Ransomware abgesehen, hast Du mit einem NAS, das zwar ausgeschaltet aber zumindest kabelseitig verbunden ist die Gefahr, dass bei einem Blitzeinschlag in der Nähe das Backup auch gegrillt werden kann.

Die HDD kann auch runter fallen, mein Haus kann abbrennen, die gesamte Stadt kann absaufen oder es gibt wieder einen Meteoriteneinschlag wie vor gut 65 Mio Jahren.

Aber vermutlich traue ich einfach nur meiner recht modernen Hauselektrik zu viel und ich hatte (im Gegensatz zu exakt einem Verwandten in eimem Haus mir vorsinnflutlicher Elektrik) die letzten gut 50 Jahre mehr Glück damit wie mit meinen ext. HDDs und meinem Willen, immer an das Backup zu denken.

All das muss jeder für sich und seine Daten selber bewerten.

Cloud wäre eine Alternative wenn ich hier eine 1000/500 Leitung für 50-80€/Monat bekomme (also mit Glück vor meinem Ableben, bisher gibt es FTTH mit max. 1000/40, der unfähigen Regierung sei Dank) oder wenn es nur um ein paar GB geht.

Jede vernünftige Backupsoftware kann sich nun mit diesem Backupnutzer auf das NAS einloggen und dir Backups dort ablegen, ohne dass der am PC angemeldete Benutzer (und somit Ransomware) jemals irgendwelche Rechte da drauf haben muss.

Jetzt muss man nur noch darauf vertrauen, dass die Ransomware meine genutzte Backup-SW nicht kennt oder sich nicht schon so tief in mein System eingeschlichen hat, dass sie die Netzwerk-Verbindung nach dem nächsten Backup auch schreibend nutzen kann.

 

[Rickmer]

Was soll daran schwierig sein, so lange man wenigstens dem OS seines NAS traut und das ganze nicht als professionelle Wissenschaft aufziehen will?

NPC hat die einfache Lösung ja schon gepostet. Das geht sogar mit jedem QNap/Synologie-NAS ohne dass man dort irgeindein Script selber laufen lassen müsste.

Dein erster Fehler: Dem OS trauen.
Man muss die Angriffsfläche minimieren als Schutz gegen 0-days und interne Kompromittierung - und ein NAS hat per Design eine große Angriffsfläche.

Für private Zwecke mag das 'good enough' sein (privat habe ich ein ähnliches Konzept umgesetzt, aber mit regelmäßigen offline/offsite Backups), aber mehr auch nicht.

Jede vernünftige Backupsoftware kann sich nun mit diesem Backupnutzer auf das NAS einloggen und dir Backups dort ablegen, ohne dass der am PC angemeldete Benutzer (und somit Ransomware) jemals irgendwelche Rechte da drauf haben muss.

Wenn die Software die User-Credentials auslesen kann, kann es ein Angreifer auch. Wenn man einen Schlüssel so absichert, dass ein Angreifer nicht mehr dran kommt, kommt auch die Backup-Software nicht mehr dran.

Wobei das zugegeben eine 08/15 Ransomware sowas vermutlich nicht mit im Paket hat.

 

[guzzisti]

Die HDD kann auch runter fallen, mein Haus kann abbrennen, die gesamte Stadt kann absaufen oder es gibt wieder einen Meteoriteneinschlag wie vor gut 65 Mio Jahren.

Jap...mal vom Meteoriteneinschlag abgesehen hilft eine mehrstufige Backup-Strategie.
Man muss sich halt überlegen wovor man sich schützen will und was man bereit ist an Aufwand in Kauf zu nehmen. Risikoanalyse halt - Schadenspotential und Eintrittswahrscheinlichkeiten schätzen und mit Kritikalität der Daten sowie Aufwand zu Mitigation des Risikos ins Verhältnis setzen.

Es gibt so kleine Helferlein wie Terminkalender oder Wecker, da kann man sich einfach dran erinnern lassen das man die externe Platte mal wieder anschließen sollte.

 

[Purche]

Jap...mal vom Meteoriteneinschlag abgesehen hilft eine mehrstufige Backup-Strategie.

Meine Backup-Stratetie garantiert mir sogar lebenslangen Zugriff auf meine Daten selbst im Fall eines Meteoriteneinschlags 👍

 

[NobodysFool]

@gymfan und @Rickmer Wenn irgendeine Ransomware die in der Backupsoftware verschlüsseltgespeicherten Zugangsdaten ausliest, dann haben wir den absoluten worst Case. Wir erinnern uns, dass in meiner Empfehlung dem aber dann noch die Snapshots entgegen stehen, dass sie auch wirklich Schaden anrichten kann. Außerdem ist mir bisher keine Ransomware bekannt, die das könnte. Wenn 1% aller im Umlauf befindlichen Ransomware dazu tatsächlich in der Lage wäre, gäbe es aber immer noch keinen Grund, sich nicht gegen die anderen 99% mit dieser Vorgehensweise zu schützen.

Man kann alles schlecht reden, weil es eben keine 100% Sicherheit gibt. Aber ich kann es denen so schwer wie möglich machen.

Und wnen mir morgen der Himmel auf den Kopf fällt, und die Sonne explodiert, dann waren meine Bemühungen auch umsonst.

 

[obuda]

Hallo,

und Danke für die zahlreichen Antworten.

Auf ein paar Antworten möchte ich auch noch kurz eingehen.

Laufwerksbuchstabe A und B würde ich leer lassen das waren mal Diskettenlaufwerke und das kann zu Problemen führen.

Das sehe ich eher als Vorteil an, solange meine Backupsoftware damit klar kommt. Desto weniger Standard desto weniger wahrscheinlich ist es, dass eine Malware die möglichst viele Durchschnittsuser erreichen soll auch Wirkung zeigen kann.

Das funktioniert so auch nicht
Das Zeug wird verteilt und es ist dann dein Pech, dass deine Daten weg sind. Egal ob Privat oder Unternehmen. Die Software analysiert ja nicht zuerst dein Gehalt und dein Bankguthaben etc^^

Meines Wissens nach hat Emotet durchaus so gearbeitet. Es hat sich eingenistet es wurde über Wochen vllt Monate geschaut welche Netzlaufwerke wann aufpoppen und wieder verschwinden. Dies geschieht natürlich nicht vollautomatisch, da muss ein Mensch am anderen Ende sitzen. Und bei meinen Urlaubsfotos wird ihm der Aufwand es nicht wert sein.
Emotet hat ja selbst Adminpasswörter über 0day Lücken rausfinden können und sich somit gut in Netzwerken ausbreiten können.

Da gibt es einen ganz interessanten Artikel "Emotet-sicheres Familien-Backup" in der c´t, siehe hier (Artikel ist kostenpflichtig). Die Überlegungen kann man den eigenen Berdürfnissen anpassen.

Das werde ich mir mal kaufen. Klingt vielversprechend. Heise hatte ja persönliche Erfahrungen mit emotet machen können.

Man könnte auch ein Nas über eine schaltbare Steckdose (per Script schaltbar) benutzen.
Bei Acronis mit dem "Vor Befehl" die Steckdose einschalten und danach mit dem "Nach Befehl" wieder ausschalten. In dem Vor Befehl müsste natürlich ein entsprechend langer Timeout mit drin sein der das booten des Nas auffängt.

Auch ein interessanter Ansatz, da ich sowieso auf dem Raspi ein Smart Home laufen habe. Da ist die Umsetzung relativ einfach - für mich.


Ansonsten möchte ich eigentlich kein NAS. Am liebsten etwas am PC per USB oder eSATA.
Nur weil ich mir eine teure Synology hinstelle, wo mein Rechner Schreibrechte hat, verringert sich die Gefahr durch Malware nicht wirklich in meinen Augen.
Wie ein Pull Backup aussehen soll ich mir auch noch nicht so ganz klar. Soll ich dann alle Laufwerke freigeben? O.o

Die "harte" Variante mit verschiedenen Platten die dann gelegentlich Vollbackups erstellen finde ich auch eigentlich gar nicht so unsexy.
Ist zwar nicht automatisiert, aber einfach eine ziemlich sichere Sache. Hier wäre meine Strategie auch eher lieber öfter auf gebrauchten Platten, als seltener auf besonders hochwertigen und teuren Platten.

 

[GrayWolf]

Also man kann nur noch mal betonen dass eine NAS ein ständiges und zertifiziertes System ist (https://www.synology.com/en-global/security) eine Platte per USB/eSATA über eine reguläre Freigabe anzubinden ist dagegen blanker Wahnsinn. Die Rechtevergabe bei einem UNIX ist auch Wasserdicht.

 

[NPC]

Warum so kompliziert? Hin- und hersynchronisieren ist ein unnützer zusätzlicher Schritt. Der PC Benutzer hat auf die NAS-Freigabe mit den Backups entweder nur Leserechte oder gleich gar keine Rechte. Auf dem NAS existiert ein extra angelegter Backup-Benutzer mit Schreib-/Leserechten, der auf dem PC gar nicht erst existiert. Jede vernünftige Backupsoftware kann sich nun mit diesem Backupnutzer auf das NAS einloggen und dir Backups dort ablegen, ohne dass der am PC angemeldete Benutzer (und somit Ransomware) jemals irgendwelche Rechte da drauf haben muss.

Wenn man jetzt noch ein NAS hat das Snapshots bietet, kann man hier noch Netz und doppelten Boden einbauen. Und wenn man dann diese Backups auf dem NAS noch synchronisieren will, dann mit einer externen Platte die man auch woanders lagert.

"Jede vernünftige Backupsoftware kann sich nun mit diesem Backupnutzer auf das NAS einloggen (...)"
Damit sind die Zugangsdaten (mit Schreibrechten auf alle die Backups!) in irgendeiner Form auf dem PC vorhanden. Eine Sicherheitslücke in Backupsoftware bedeutet dann, die Malware kann Backups löschen. Auch Backupsoftware ist Software. Jede Software hat Bugs.

"Warum so kompliziert? Hin- und hersynchronisieren ist ein unnützer zusätzlicher Schritt"
Die neue Backups werden genau 1x kopiert: von der (potenziell ungeschützen) Partition mit dem Backup-User auf die geschützte Partition des NAS-Users. Stichwort "Air Gap".

---
Versionierung, Snapshots, Replizierung auf mehrer Systeme (z. B. Cloud ink. Verschlüsselung oder komplette Offline-Backups), Hardwareredundanz durch z. B. RAID 6 oder RAID 10, eine USV, passende Retention Policy (Anzahl Backups vs. verfügbarer Datenspeicher), Time to Recovery (besonders bei reinen Cloud-Backups), Verfügbarkeit des Netzwerks bei Stromausfall... es gibt bei Backups sooo viel zu beachten.


Nimm einfach nen Linux-PC mit Windows-VM (+Backup)

Ergänzung (8. Juni 2022)

Dein erster Fehler: Dem OS trauen. (...)

Ich denke mal, der Threadersteller sucht eine bezahlbare Lösung für Privatpersonen und nicht nach einer Backupstrategie für den BND 😅

 

[Giggity]

@obuda
Ich kann nicht ganz nachvollziehen was du willst.

Externe Festplatte wäre das kostengünstige aber die muss halt abgesteckt werden. Das willst du ja vermeiden laut Eingagspost. (faule Menschen)

Die faule Methode in der du alles bekommst ist ein Backup NAS was nur zum Backup läuft. Hier reicht ein 1Bay NAS für ca. 160€ + HDD. Das ist dann wenn es aus ist auch Ransomware sicher. Klar während des Backups wäre es angreifbar aber das ist sehr unwahrscheinlich.

Die "harte" Variante mit verschiedenen Platten die dann gelegentlich Vollbackups erstellen finde ich auch eigentlich gar nicht so unsexy.

Das kann man machen ist aber auch mit Anschaffungskosten verbunden Klonstation, mehrere Festplatten und hier musst du mehrere Festplatten manuell klonen. Das ist viel mehr Aufwand als eine externe Festplatte abzustecken.

Hier ist eigentlich schon ein unregelmäßiges Backup vorprogrammiert. Dafür ist allerdings das Konzept relativ einfach zu verstehen und umzusetzen.


Die eierlegenden Wollmilchsau für lau gibt es nicht.

 

[Ranayna]

Ganz wichtig ist es, die Backups zu pruefen. Idealerweise auf einem separaten System.
Denn es hat schon Ransomwarevarianten gegeben, die erstmal nicht sichbar aktiv werden, sondern erstmal alles transparent verschluesseln, und ein paar Wochen warten. Dann sind oft die Backups von vor dem Befall rausrotiert, mal abgesehen von den neuen Daten die waerend des Befalls angefallen sind.

Das faellt allenfalls auf wenn man die Datentraegerauslastung waehrend des Verschluesselns bemerkt, die allermeiste Backupsoftware duerfte das beim Backup nicht bemerken, und selbst eine hashbasierte Verifikation kann ausgetrickst werden.

Das merkt man aber dann, wenn man mit einem anderen Rechner versucht auf die Daten zuzugreifen.

 

[Purche]

Moment mal, entweder die Verschlüsselung durch die Ransomware erfolgt zunächst transparent oder nicht.
Wenn die Verschlüsselung transparent ist, liegen die Dateien zwar verschlüsselt auf dem Datenträger aber Zugriffe aller Anwendungen darauf werden transparent entschlüsselt. Das betrifft somit dann auch die Backup Software, d.h., alle Dateien, die sie in ein sauberes System im Netzwerk sichert, sind dann im Backup weiter intakt.
Erst wenn die Ransomware fertig ist und die transparente Entschlüsselung deaktiviert könnte ein Backup-Vorgang auch verschlüsselte Dateien ins Backup übertragen und dort im worst case intakte Dateien überschreiben. (Vielfach merkt eine inkrementell arbeitende Backup-Software aber gar nicht erst, dass der Dateiinhalt verändert - da verschlüsselt- wurde: wenn die Ransomware Dateiname inkl. Zeitstempel beibehalten hat. In diesem Fall bliebe die Datei im Backup bis auf weiteres auch noch intakt.)

Hauptsächlich bei einem sektorweisen Klonen der Platte wäre ein in der transparenten Phase erstelltes Image unbrauchbar...