Ransomware dangers increasing

[greengeek]

There are huge increases in numbers of people suffering from Ransomware attacks and having to fork out big dollars to have their files unencrypted.

I guess it is not so bad if the unencryption key is actually made available - but how long will it be until unencryption keys are not made available and significant damage is done by criminals who are out to destroy companies or individuals rather than merely rob them for unencryption cash?

Worryingly it appears that the latest ransomware variants are targeting well backed up systems and doing their damage slowly over an extended time so that the encryption runs deep across your whole file system before you even discover it or get informed of it by the perpetrator.

Good article here:
https://www.techopedia.com/the-ability- ... er/2/32083

[musher0]

Hi, greegeek.

Is it this day of the lunar cycle aqain? (I noticed that a thread about
Puppy security is created on this forum +/- every 28 days...)

Joke aside, the solution is mentioned in the article you referenced:

"By backing up your data at regular intervals every day, your
IT team can bring your data back from encrypted purgatory,
circumventing the need to pay a high-priced ransom."

By doing daily backups, you'll only be set back a couple of hours should
an incident occur. Puppy has all kinds of tools to do backups.

Additionally, one should consider that web writers such as this Brad Rudisail
are paid to spread paranoia among readers!

BFN.

[greengeek]

Fair enough. So how often do you think Puppians backup their data? Do you think they do so at intervals - several times during the day?

I bet most puppians only backup at most every 28 days when someone raises a "paranoid" issue.

In fact plenty of puppians woud only back up their data drives once a year or similar interval. Just my hypothesis anyway.

The reason that I consider this a significant issue is that I experienced a ransomware threat that locked up my browser and my entire machine. Cutting power was the only way out. However on a laptop there is a battery that keeps the system running when you pull the power cord. Which lets any current encryption activity carry on it's merry way.

So I feel every puppian needs to think about what exactly they do to protect their data when under direct threat. The threats are not decreasing they are increasing.

[musher0]

Oh, you're right.

Most Puppyists and computer users have a bird's brain and a naive belief
in magic when it comes to back-ups.

Yet it's so easy on Puppy. We have a de facto back-up of our Puppy
system in the form of the ISO file we downloaded.

After that, all we need is use SFR's PackIT on our pupsave file every
second day, and that's pretty much it.

And if you'll allow me to toot my own horn, I've produced a script that
saves the new stuff from your session at shut-down. Or at five to midnight
if you're burning the midnight oil and straddling two days. Not quite the
regular intervals during the day that the writer of the article recommends,
but almost. For an individual user, it should be enough.

I can't remember where I go this from, but it stayed with me because it
makes so much sense:

"The Rule #1 of computing is back-up, back-up, back-up. Back-up your
personal files daily, your directories weekly and your partitions monthly."

~~~~~~~~~
What happened to your files and computer after that failed ransomware
attempt? Lots of loss and damage? Were you on a Puppy system?

About emergency shut-downs: how about holding down the reset button for
8 seconds? It works here.

IHTH.

[souleau]

I work from a frugal install on USB stick, and I have a two fold backup plan.

Whenever I am about to make any change in my setup, I will create a backup of my savefile on the harddrive.

I also have a second USB stick, on which I have made an entire copy of the USB stick I am working on at some point in time.

If shit would hit the fan for some reason, I can just copy the savefile back from the harddrive (which, incidentally is only mounted for the sake of backing up), and if it would turn out that the savefile, or entire usb stick would have been comprimised for some time, then I could always revert to the second USB stick, which would mean I would have lost a considerable portion of work, but it would not be the end of the world.

I also run a strict NoScript setup on Firefox, and I do not allow Flash.

[greengeek]

What happened to your files and computer after that failed ransomware attempt? Lots of loss and damage? Were you on a Puppy system?

Hi Musher - I will start with your last comments first - Yes I was on a puppy system, in fact the same one I am using today - a personal derivative of Slacko 5.6. It has no savefile - only a personalised sfs that contains my personal and localisation specific changes.
None of my files (as far as I can tell) were affected. I shut down immediately as you suggested by using the power key held down for 10 seconds.

However - given that my derivative does not use a savefile (nor a savefolder) I feel that the minimal (non-existent? ) damage was not as bad as could potentially have been the case if a savefile or savefolder was in use - or if drives had been mounted.

In years prior to using this derivative I did experience data losses and that is what drove me to shun savefiles. (I don't exactly know what caused those multiple episodes of data loss but I have never experienced any since getting rid of savefiles).

Anyway - I now feel that there is a potential major risk to important data if our personal files are accessible (mounted? or attached?) when we are online so I feel it is worthwhile highlighting the significant risk if our files get encrypted for some reason.

Yet it's so easy on Puppy. We have a de facto back-up of our Puppy system in the form of the ISO file we downloaded.

True if you consider the "system" files - but what about all of the personal info we keep on other drives? - photos? CVs? Family histories (geneaology), drawings, graphics, stories, commentaries, instructional pdfs etc etc that we acquire over a lifetime?

What if a hacker slowly encrypted a portion of those files every time we went online? We may never recover that data.

Most Puppyists and computer users have a bird's brain and a naive belief in magic when it comes to back-ups.

After my hiccup where I received the encryption threat I realised that I had no real way of preventing a browser lockup, and no real confidence that I could prevent (or recover from) any hacker who had the expertise to remotely access my system. I had every confidence that I could restart my puppy files in a virgin condition (I do this at every boot as I discard any changes from the previous session) but no idea if they may have accessed any of my disks.

Could they have mounted and accessed my offline disks? - I had no idea. What I realised is that it might be worthwhile to make sure that my online session was on a machine that had no physical access to my disks (mounted or no) at all.

After that, all we need is use SFR's PackIT on our pupsave file every second day, and that's pretty much it.

Is every second day enough? I have no savefile so this is irelevant for me - but the article suggests that a running backup occurring multiple times per day is valuable. I guess it depends how much data you change/add /delete per day.

And if you'll allow me to toot my own horn, I've produced a script that
saves the new stuff from your session at shut-down. Or at five to midnight if you're burning the midnight oil and straddling two days. Not quite the regular intervals during the day that the writer of the article recommends, but almost. For an individual user, it should be enough.
I can't remember where I go this from, but it stayed with me because it
makes so much sense:

"The Rule #1 of computing is back-up, back-up, back-up. Back-up your
personal files daily, your directories weekly and your partitions monthly."

Or multiple times daily perhaps? Either that or keep personal disks offline (out of the computer) at all times - just run a live session with no attached storage devices.

About emergency shut-downs: how about holding down the reset button for 8 seconds? It works here.

True - but what can happen in that 10 seconds?

A few years ago you wrote me a script that immediately unmounts any mounted disks and shuts down the system. Doesn't wait for snapmergepuppy or anything - just shuts downs. Faster than 10 seconds (at least if the system is still running and lets you access it!)

[musher0]

Hi greengeek.

I can't remember, frankly! Probably something based on typing
< busybox shutdown > in console. That's immediate, but your may lose
the data files you're working on at that exact moment.

As for me, I'll touch wood. I never had a data loss problem caused by
external human sources. By my own inexperience, stupidity or oversight,
yes. By hardware failure, yes.

You could write a short story with what happened to you, couldn't you?

I don't have to change my "dailies" script, not for regular runs during the
day anyway. That part has already been written! I mean that using
zigbert's scheduled run utility is one good way to have my script -- or the
back-up tool of your choice -- run at regular intervals during the day.

BFN.

[musher0]

I work from a frugal install on USB stick, and I have a two fold backup plan.

Whenever I am about to make any change in my setup, I will create a backup of my savefile on the harddrive.

I also have a second USB stick, on which I have made an entire copy of the USB stick I am working on at some point in time.

If shit would hit the fan for some reason, I can just copy the savefile back from the harddrive (which, incidentally is only mounted for the sake of backing up), and if it would turn out that the savefile, or entire usb stick would have been comprimised for some time, then I could always revert to the second USB stick, which would mean I would have lost a considerable portion of work, but it would not be the end of the world.

I also run a strict NoScript setup on Firefox, and I do not allow Flash.

That's a pretty good data safeguard strategy you have there, souleau.

[Sailor Enceladus]

Hi Musher - I will start with your last comments first - Yes I was on a puppy system, in fact the same one I am using today - a personal derivative of Slacko 5.6. It has no savefile - only a personalised sfs that contains my personal and localisation specific changes.
None of my files (as far as I can tell) were affected. I shut down immediately as you suggested by using the power key held down for 10 seconds.

However - given that my derivative does not use a savefile (nor a savefolder) I feel that the minimal (non-existent? ) damage was not as bad as could potentially have been the case if a savefile or savefolder was in use - or if drives had been mounted.

In years prior to using this derivative I did experience data losses and that is what drove me to shun savefiles. (I don't exactly know what caused those multiple episodes of data loss but I have never experienced any since getting rid of savefiles).

Hi greengeek,

I'm curious, what is changed in your Slacko 5.6 derivative, and is it available for download anywhere?

[perdido]

Assuming this threat of ransomware is internet based, it is easy to create a limited user account and run your browsing session in the limited user account.
Or use Spot even....

To create your own limited user account see here
http://www.murga-linux.com/puppy/viewto ... 81&start=6

Be advised that by creating a limited user account in this manner will isolate your browser from everything on the system that requires root.


Running around the internet as r00T or Administrator is what is really the risk.

Personally, I prefer the Lobster solution http://zapatopi.net/afdb/
The link is a direct copy from the growl2.1 from Lobster.
Notice the evil http link and click at your own peril!!!

All joking aside, create a limited user account and also backup your important stuff. How much important files can a person have? I mean really really important, like sacred family pics and such.

Pron does not count as important and if a person stays away from sketchy sites like ebay, google and amazon then your chances of encountering eVIL hACKER d00ds is lowered.

If you wander around the really creepy places just create a limited user account and run TOR, that will effectively sandbox your session.

.

[spiritwild]

That's true about nieve. Where I work, It's a double edge sword. A mix of "it's not my job to back stuff up" and the IT guy just wiping everything and starting over.

At least three times, he has wiped their stuff and they did nothing to back stuff up. Of all the online storage, and falling prices of usb sticks, it's just amazing to me. One girl had 75 gigs of music and her pc had come to a creeping halt. Out of space and pop up warnings left and right. I told her to get a usb or storage account and keep what she valued off the company pc. She insisted that she shouldn't have to and the company should buy it.

What??? it's your personal stuff!! Anyway, I managed to salvage her email addresses and photos. I really didn't care about music. He tells them that everything is lost and they get upset. Even though they did nothing to prevent it. I don't understand that thinking. I mean, it's not his job to salvage personal files considering it's a work pc but he knows they are going to do nothing to help themselves. Why should he go the extra mile?

Then again, they let their trash cans flow over onto the floor because we have office cleaning at night. So there is this mental entitlement issue going on in their heads. "nothing is their own responsibility or burden anymore".

For me to take the drive home and recover stuff is just something I do as a favor. Even though they still blame him and remove themselves from any wrong doing.

The same thing happens with automobiles. Being a mechanic, the simplest fix or preventive maintenance seems to be rocket science anymore. Of coarse, research is out of the question so we just take it to the mechanic. 1200 dollars later, we have a new coil pack. something that use to be a $2 spark plug wire issue is now a $125 part that cost $800 to screw on in 6 minutes. good lord.
And for %^&$! sake, a loose gas cap is not the solution to every problem on earth yet they relish in wonderment of this amazing mechanical voodoo.


I digress. I back up all the time. I have a mix of scripts and commands that I save daily but I try to back up once a week. It becomes tedious at times with all the changes that seem to occur. alsa and firefox, my conky conf that I cant seem to ever leave alone. etc, etc.

I will say, rcrsn51's SaveFolderBackup-1.2.pet has proven to be one of my favorite backup utilities.

http://murga-linux.com/puppy/viewtopic.php?t=110090

Much reccomend for speed and ease of use.

[drunkjedi]

I had come across a ransomware last year, a friend of mine got teslacrypt.
I made a thread at that time about it.
http://murga-linux.com/puppy/viewtopic.php?t=106331
I searched for solution for sometime then gaveup.
He may still have those files. I will look again if a solution can be found.

[rufwoof]

Slow creepage encryption of your data files could be a right pain. Op system wise much less so ... for instance I can just download Debian LiveCD and have new frugal boot version up and running in next to no time (few hours perhaps of reapplying tweaks etc.). Same if the bootloader gets over-written (one ransomware apparently replaced the MBR with its own grub4dos menu ... that simply demanded $$$'s and where to send them when you tried to boot the PC).

Toying with the idea of creepage I got around to thinking about perhaps using sfs's and a layered filesystem approach for data files. Frugal read only Puppy (remastered/recreated to how you like it and then booted read only thereafter), alongside aufs layered sfs's for your data files ... and you could roll back to historic versions if the need arose.

As a quick test I ran

Code: Select all

#!/bin/bash

# As a test let's make 30 sfs's
for i in $(seq 1 30); do

  mkdir $i
  echo i >$i/$i.txt
  mksquashfs $i $i.sfs
  rm -rf $i

done


# Mount the 30 sfs files
for i in $(seq 1 30); do

  mkdir $i
  mount -o ro,loop $i.sfs $i

done

# Create a merged folder (aufs-dir) and a folder
# that records any changes (changes-dir)
mkdir changes-dir aufs-dir

# Form aufs mount command parameters
COMMAND=" -t aufs -o br:changes-dir=rw"

for i in $(seq 1 30); do
  COMMAND="$COMMAND,br:$i=ro"
done
COMMAND="$COMMAND none aufs-dir"

mount $COMMAND

Which produced 30 sfs's each containing just 1 file i.e. 1.txt in 1.sfs, 2.txt in 2.sfs ... etc. When aufs mounted aufs-dir contains the image of the whole set (1.txt, 2.txt ...etc) and changes-dir contains any changes made in aufs-dir such as deletion of files (.wh whiteout files) or additions/changes.

In practice 1.sfs might contain all of your data files at day 1, and 2.sfs formed by making a sfs of the changes-dir folder before shutdown i.e. all changes to data files made that day. Then the next day a 3.sfs file is created from changes-dir folder for that day .... etc. When aufs mounted you see all of the data files and the changes made, but could 'roll-back' to any prior days snapshot of those files.

For backup, make a single sfs of all of the sfs's and encrypt that before uploading to your cloud based (offsite) server. Perhaps after a visual inspection indicates all looks OK you might even just use that as 1.sfs and start all over again (no naughty encryption apparent ... OK to merge the set and restart all over again type of thing).

Note that I ran the above under Debian Frugal, which accepted 30 loop's OK. Not sure what the maximum number might be, but IIRC puppy's limit is lower for some pup's (as few as 6 perhaps ???). Again IIRC it's not difficult to up the maximum number of loops however.

Personally I have a sym link in my read only 'pup' that links out to my persistent DOCS folder, so that any changes made to docs/images etc in that folder during a session are preserved across reboots. Just a matter of policy to perhaps change that to mount the aufs-dir as per the above as the DOCS-persistent folder instead, and a additional shutdown code to produce a sfs from changes-dir.

If the virus program changed copies of data files that puppy 'sees' then those changes would be preserved in that particular days sfs (changes-dir, that gets moved into a day number sfs (3.sfs for instance)), leaving the original still intact (in 2.sfs or the main 1.sfs for instance). If the virus encrypted the sfs files themselves ... then they'd simply not load which would be a key that something was amiss ... i.e. look to download a backup from the cloud.

EDIT : I can confirm that DebDog 32 has a 7 loop limit (running the above code and only 7 sfs's appeared in aufs-dir). Extracting Tahr64's initrd.gz and it looks like that's set at 10 loops maximum (around 3/4 of the way down init) ... which also includes a mention that performance degrades with higher numbers of loops.

[rufwoof]

I've been experimenting some more with a documents layered filesystem arrangement that could add some additional protections against ransomware ... here are some notes that may be of interest. Doesn't protect against the likes of master file table/inodes encryption attacks or MBR ...etc, so as-ever regular backups are still the best overall choice of protection.

# Make a sfs of your DOCS folder
mksquashfs DOCS docs.sfs

# Mount it
mkdir mountpoint
mount -o ro,loop docs.sfs mountpoint

# Create a folder to store any changes
mkdir changes-dir

# Create a folder to use as your documents folder general use, i.e. the one that
# you'd actually access/use such as editing a document or adding a picture to ...etc.
mkdir aufs-dir

# aufs mount
mount -t aufs -o br:changes-dir=rw,br:mountpoint=ro none aufs-dir

If you sym link that aufs-dir from your puppy home folder then any changes to files in that aufs-dir folder will be recorded in changes-dir

At session end umount aufs dir and mountpoint
umount aufs-dir
umount mountpoint

and the changes-dir will still hold all of the changes made to the content of docs.sfs (your documents) ready for the next rebooted session. You just have to remount it again as before

mount -o ro,loop docs.sfs mountpoint
mount -t aufs -o br:changes-dir=rw,br:mountpoint=ro none aufs-dir

After a while you might want to merge the two, perhaps after having checked out the content of changes-dir to make sure nothing looks unusual/wrong

mksquashfs aufs-dir docs1.sfs

and you can then umount aufs-dir

umount aufs-dir
umount mountpoint

delete/recreate (empty) changes-dir
and then mount the new version

mount -o ro,loop docs1.sfs mountpoint
mount -t aufs -o br:changes-dir=rw,br:1=ro none aufs-dir

If you make a sfs of the changes.dir, a quick way is to use no compression

mksquashfs changes.dir changes.sfs -noF -noX -noD -noI

that last one is a capital i (-no and a capital i). Larger sfs size, but runs through quickly.

mountpoint files are read only (mounted copy of docs.sfs)
docs.sfs being a sfs is read only. All a casual virus/ransomware could do is perhaps encrypt files in aufs-dir, but those changes would just recorded in changes-dir (originals still intact in docs.sfs). Docs.sfs is read only (sfs) which even assuming it was somehow encrypted is just a copy of your actual Docs folder files that ideally would be stored elsewhere/safely. Periodically you might want to either form a new copy of the aufs-dir content to store off site/safely (incremental backup copies).

Note the above all assumes aufs is being used. Debian Jessie was aufs based but the next release (Debian Stretch) will be using unionfs. You can however work around that by adding aufs-dkms (from Stretch repository apt-get install aufs-dkms) and including union=aufs as a kernel boot parameter. The above also assumes that you have mksquashfs installed (for Debian that's apt-get install squashfs-tools).

[musher0]

Hi rufwoof.

Interesting approach. Although implementing it sounds like a lot of time
and trouble.

I still think archiving the pupsave with a quick archiver such as lzop or lz4
is a simpler way. Plus my "dailies" script, running at scheduled intervals
during the day if you like, should be enough for an AVG individual user or
even a power user.

For a company, you'd need a different strategy. Perhaps a RAID set-up?
Or your strategy: I can see an employee doing that half-time, say, in the
afternoon, for a number of Puppy work stations.

~~~~~~~~
For the record, French forum member "ASRI Éducation" did an exhaustive
test a couple of years ago and observed that the maximum number of sfs
archives sfs_load can load is 122. At sfs # 123, his Puppy started acting
weird. I have to find that thread again in this bazaar of a forum!

Yes, you read that correctly! One hundred and twenty-two sfs files can be
safely loaded in a Puppy through sfs_load. The total is actually 128, but five
spots are reserved: main puppy.sfs, zdrv, and optionally adrv, fdrv and
ydrv; plus of course the pupsave file.

BFN.

[musher0]

Hello again, guys.

This keeps bugging me about the safety of systems.

Greengeek, I don't suppose you recall the type of language used to penetrate
your system. I'm thinking css, since you mentioned the gateway appeared to
be the browser, but I'm probably wrong. (I know nothing about css, BTW.)

We wouldn't have to do complex back-ups if we had a good "bouncer". Yeah,
like in bars! Some drunk kiddo comes in to make trouble, back out he goes!
Or he's put in a padded room until the cops arrive. You get the analogy, I'm
sure.

gcmartin I think had found a program like that perhaps 2 years ago. Except I
didn't have the knowledge to use it properly. (I probably still don't!)

When it discovered an unwanted URL on your system, it turned the tables on
the originator, and started sending fairy tales to that URL.

That would be like switching from defensive to retaliation.

Other safety measures discussed in earlier threads: (jogging my memory!)
Using "700" permissions (or "user only") on all possible files. An outsider can't
change a file he doesn't see.

Manual probing of unwanted connections with < lsof -i -r x >. (An x seconds
interval)

User jafadmin had a trick for locking files or somthing like it? (Not fresh in my
memory, have to look it up again.)

If you have any other interesting safety knowledge, please contribute. TIA.

BFN.

[greengeek]

I don't suppose you recall the type of language used to penetrate your system. I'm thinking css, since you mentioned the gateway appeared to be the browser, but I'm probably wrong. (I know nothing about css, BTW.)

As I recall there was a large dialog box (something like a yafsplash notification) in the middle of the screen and i was unable to move the mouse or get any response from keyboard. I really don't know what code/language was driving the dialog.

The dialog advised me that all of my files were in the process of encryption and I would have to contact a specific website to obtain the unlock key and it would only be provided upon payment of a certain ransom.

The inability to regain control of my system sent me into a panic and pulling the power was the only option.

My gut feeling was that if they had a technique to lock me out then they could equally have a method to access my system and potentially even be able to run kernel commands (mount, etc) and do real damage.

Of course it may be that their code could only run on Windows - but in any case it was a nasty feeling that their code locked me out (or maybe some browser issue locked me out because their bad non-Linux code was enough to put the browser into a tail spin...)

The one good thing that came out of it was that I had confidence that dropping power on my system would not corrupt my puppy - for the reasons that rufwoof and others have often stated - that personal sfs files are more sturdy than savefiles.

[greengeek]

I've been experimenting some more with a documents layered filesystem arrangement that could add some additional protections against ransomware ...

I wonder if it would be possible to have a puppy set up so all the system files are effectively readonly (the usual personal sfs style...) but any documents/pics/personal files etc were locked up in a layer protected by "Spot" user or else by your own form of encryption lock, or else mounted as readonly but with some form of "write lock" which allows you to modify the files only when you enter a personal password or similar.

Like a sandbox layer for personal stuff (switchable readonly / writable)

[greengeek]

I'm curious, what is changed in your Slacko 5.6 derivative, and is it available for download anywhere?

I used a technique I learnt from forum member jrb - you can change the initrd.gz "DISTRO SPECS" file in such a way that it swaps the main puppy sfs and a "personal sfs" (being used as a zdrv).

This allows your personal changes (captured in an sfs) to override the basic "main" puppy sfs. It also makes your puppy read only so that your personalisations are not kept in a read/write savefile - they are encapsulated in a readonly sfs so that every boot is pristine - exactly as you set it up originally - despite what may have happened in the previous session.

This makes it robust so that you can fiddle to your hearts content - try whatever software you want - and it will not adversely affect your puppy. Even if you did catch malware from a bad website it will not be retained or hang around to do any damage next time you boot.

I have just uploaded my latest variant which is quite big at 459MB as it incorporates LibreCad, LibreOffice, Firefox, Google Chrome and various other tidbits that make it just right as my complete daily puppy.

You just boot the generic version, add whatever personalisations you want, then click the "impersonator" icon and it will burn you a new iso to CD, DVD or will build you a new personal sfs for use in a frugal installation.

If you want to try it see second half of this post here:
http://www.murga-linux.com/puppy/viewto ... 675#813675

[rufwoof]

Interesting approach. Although implementing it sounds like a lot of time and trouble.

I still think archiving the pupsave with a quick archiver such as lzop or lz4
is a simpler way.

Once you have a system set up the way you like it you might not be running with a save at all i.e. a remastered puppy configured exactly how you like it booted each time, no saves performed, all data/docs being stored outside of puppy. Using the aufs layering of those docs could then be useful. Basically instead of the actual docs folders/directories you use a sfs of those docs and mounted the way I described (couple of lines in startup) all changes are recorded in the changes folder, not to the actual files. A good thing is that the changes are being recorded/preserved instantly without having to run a save.

Quite simple/easy to implement and once established just a matter of something like
mount -o ro,loop docs1.sfs mountpoint
mount -t aufs -o br:changes-dir=rw,br:1=ro none aufs-dir
being included in the startup

Can become complex depending upon how you want to manage the layered docs files. Docs/data files are used to create a docs.sfs which when mounted as described has a changes-docs folder containing all changes to those docs ... how do you manage that once changes-docs (in effect a docs save file) becomes large. Do you 'remaster' it into a new docs.sfs (leaving a empty changes-doc 'save folder'). Or perhaps just manually copy changed files across to the master docs/data folders/files and recreate a new docs.sfs from that ... Or what. The manual copy seems a nice choice as you're in effect manually validating each and every changed file before putting it into the 'safe' (main docs/data files/folders that is/was used to create docs.sfs). You could make things as complicated as you liked, for instance have multiple layers of changes.sfs ... one for each day perhaps so that you could roll back to historic snapshots of data/docs.

For example in my case I use a pure-debian (main repository only) choice to create a frugal installation. So create that from fresh, set it all up as you like and then lock that down as a read only (remastered like) version that is booted the exact same every time (read only, no saves). Only remastering that to perhaps apply updates periodically. If that were lost/corrupted by a virus/whatever ... no big deal, just means having to install from fresh (debian repositories) again. For more valuable data (birth/wedding photos etc.), instead of working on that data itself you'd be running using copies of those data, along with a changes folder of any additions/changes. Ideally with the originals locked away in a physical safe, out of harms way. Comprised of a data.sfs (sfs read only copy of the data files) and changes-dir ... running in the background, and a aufs-dir that you use to access those data/docs i.e. perhaps sym linked into your home directory/folder (likely with a better name such as MyDocs or whatever), where all changes are recorded instantly without having to perform a save.