I know that this is similar to this question, but I don't believe it's a duplicate.

You have a program that automatically makes regular backups of all your files to a folder or mounted drive.

Let's say you configured your system so that the only process that has write access to that folder/drive is the process that performs the backups.

Would this significantly decrease the likeliness that various ransomware programs would be able to touch the contents of that drive/folder?

Would it at least protect against ransomware programs that run without root/administrator privileges?

Is there any chance at all it could even protect from those that have acquired root/administrator privileges? (Do most ransomware even have that?)

I guess in a really bad scenario, where the ransomware is very cleverly written and equipped, there is nearly always a chance that it could use various ways to get around most things. While that is interesting, I'm mostly interested in a practical situation, and what may actually happen if real life ransomware was confronted with such a situation. (Write access to backup directory is limited to only the process that does backup.)

If this would indeed help protect us, is it relatively easy to set it up on various desktop operating systems?

I'm not only interested in Windows, as there has also been confirmed cases of ransomware on Unix/Unix-like operating systems.


2 Answers 2


Having a read-only backup directory that is only accessed by a backup user will have a positive impact on the number of ransomware that can destroy/alter your backups. Depending on this solution solely will not fully protect your system.

There's a number of factors regarding ransomware out there, which means that a comprehensive anti-ransomware strategy would have to be used. I did some basic research, and found that while some ransomware would be thwarted by this alone, it's not foolproof. Here some other helpful tips:

Unmount Backups

As long as the files are accessible at the kernel level, there's some chance of a privilege escalation attack that could bypass file permissions. Preferably, your back up should exist on a dedicated machine connected through the network and has to be mounted by the backup user before copying files. This reduces the exposure time for those files to be encrypted.

Network Backups

Don't keep the backup on the same computer as you're using. This is also practical in the sense that when your hard drive crashes, you can go to your backup and restore from there. They do go bad from time to time. I had a hard drive just this year start throwing unreadable sector errors, and it was a backup (but had already been backed up itself before it went bad).

Run As Normal User

Many users decide to run as local administrators (especially Windows users), which makes privilege escalation easier or not necessary. Make sure you're only logged in as root/Administrator to install programs, and run as a normal user at all other times.

Rename Files

Come up with a naming scheme for your file extensions. Most ransomware actually only looks for certain types of files, like pictures, movies, documents, and spreadsheets. Things that you tend to care about. If your backup files have different extensions, most ransomware will happily ignore those files in favor of files it thinks you care about.

Patch Systems

Many ransomware packages depend on exploits in Java, Flash, a specific browser or Operating System, or a driver. Make sure you patch your software as frequently as possible. Drive-by infections are still common, although most drive-by software tends to not use privilege escalation attacks as of late, so simply keeping your software up to date could be a major bonus. This includes third-party software like Magento, Drupal, and so on.


Keep an anti-virus program running on your machine, with heuristic matching, if available. Most vendors have learned to tell when a ransomware is up to no good.

Honeypot (?)

I don't know of any off-of-the-shelf products that do this, but you could build a honeypot in your file system in just a few lines of code. Basically, make a folder named "a" in your home directory (/home/a or /Users/a), and write a small program that hooks into the ioctl for that folder. Terminate any program that attempts to read from that directory. Alternatively, just write a daemon that hooks on your backup folder, and terminate any programs that don't have the backup user's id attached to it.

Keep in mind that there's still other ways to mangle your files. In theory, a hypervisor virus could gain control of your hardware and corrupt everything without you even knowing about it, until it was too late. No scheme you could come up with will be 100% foolproof. However, by carefully managing your backups offline, patching regularly, and restricting your user account's privileges, you'll keep the majority of the ransomware in the wild from harming you. This is the same basic strategy you'd use to protect against any other type of virus.

  • Is it worth adding another approach, where the endpoint system being backed up has no access to its own backups? So it's not just that the backup storage which is remote on the network, but the endpoint is not able to write to that remote storage. I think this is the approach taken by BackupPC backuppc.sourceforge.net/info.html
    – bdsl
    Jun 24, 2017 at 14:31

To your point: "Is there any chance at all it could even protect from those that have acquired root/administrator privileges? (Do most ransomware even have that?)"

Most attacks these days involve a breach, elevated credential harvesting, and then subsequent mayhem when domain admin control is achieved (AV & Endpoint turned off, payload/script pushed to every endpoint at 2am Sunday...).

Backing up to non-partitioned local, or visible drive will not offer any protection these days. The attacker will easily spot it, and either wipe or encrypt it in the process.

Your backups need to be completely segmented off your network, with access only available to a small number of admins that utilize strong 2FA.

Anything less is playing with fire.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .