[Feature Suggestion] Protecting FreeFileSync backups from ransomware

[kRel]

To keep safe my backups created by FreeFileSync I keep the backup drive alwais disconnected from my computer

This method is the safest, but it is inconvenient and does not allow scheduled backup procedures, so I make backups only when I remember

Is it possible to set up in FreeFileSync a security system that makes it impossible to change backup files from ramsoware?

[Plerry]

How do you imagine that?
Something like that would need to be addressed at OS level.
And it sort of is, and is called user access control.

If you run your FFS sync(s) under dedicated sync user/password credentials
and give only that user write access in your backup location, and (as far as required)
all other users (preferably incl. system and admin users) only read access
in your backup location, you are already in much better shape.

If you only mount (logically connect) your backup location before running the sync
(and only for said sync user) and dismount (logically disconnect) it after the sync,
you are in even better shape. Such (did)mounting could be a drive mapping in WIndows.
Logically mounting and dismounting drives could be done in a batch-file, that mounts
the drive/location, launches FFS, and dismount it after FFS has run its sync.

And the ultimate step (as you already describe above) is to only physically connect
the backup location during the time the sync is running.

[Lady Fitzgerald]

I always run full scans with my AV and other antimalware programs before updating backups.

[SinusPi]

This could be addressed by noticing large-scale file replacement operations. If a folder is suddenly getting all (or most) of its files replaced, and a simple file type ("magic bytes") check detects the files no longer match their extensions, then it could cause a red flag, for the user to take manual action. After all it's not common for a C:\PICTURES folder to suddenly have all its 1000 JPGs replaced with apparent garbage - it's clearly either ransomware or data corruption.

[kRel]

How do you imagine that?
Something like that would need to be addressed at OS level.
And it sort of is, and is called user access control.

If you run your FFS sync(s) under dedicated sync user/password credentials
and give only that user write access in your backup location, and (as far as required)
all other users (preferably incl. system and admin users) only read access
in your backup location, you are already in much better shape.

If you only mount (logically connect) your backup location before running the sync
(and only for said sync user) and dismount (logically disconnect) it after the sync,
you are in even better shape.

Such (did)mounting could be a drive mapping in WIndows.

Logically mounting and dismounting drives could be done in a batch-file, that mounts
the drive/location, launches FFS, and dismount it after FFS has run its sync.

And the ultimate step (as you already describe above) is to only physically connect
the backup location during the time the sync is running.

quite right !

Thinking better, I realized that FFS can not activate these protections that must be activated at the OS level.

Very good your suggestion to restrict the writing to my users. The only limitation could be that you are no longer able to log in with that specific user. but it is a solvable problem.

Regarding your second suggestion, having Windows, I do not understand how I can mount the units since windows mount automatically.

Thanks !

[Plerry]

For drive-letter mapped network locations, you can tell Windows if you want those drives to be reconnected during the next logon or not.
And by running command-line "net use ..." instruction, you can tell Windows
* to mount a mapped drive by using "net use [driveletter:] [\\computername\sharename[\volume]] [/persistent:{yes | no}]", where persistent:yes remount the drive at next logon, and persistent:no does not.
* to dismount a mapped drive by using "net use [driveletter:] [delete]"

By having a batch script that mounts the backup location, then runs FFS and then dismounts the backup location, the backup location is only mounted during the FFS sync.

[el_sabio_]

I join the request that FFS can mount the unit or drive at the beginning of the copy and at the end of the copy that can to dismount a mapped drive

[Lady Fitzgerald]

There are many reasons why automated backups are a bad idea. To be able to automate a backup, the destination drive needs to be connected to the computer at the time the backup is to take place. That normally means the drive is connected to the computer full time, leaving the drive vulnerable to data loss from a variety of dangers, such as power surges burning up the drives, floods, fire, theft, etc. Even if a drive is dismounted, a virus could remount it.

For a backup to be a true backup, it must be kept disconnected from the computer and the power source and stored somewhere other than in the immediate vicinity of the computer, preferably out of sight. It should be connected to the computer and power only while a backup is being backed up. To avoid accidentally contaminating a backup with malware, complete antivirus and antimalware scans should be run immediately prior to updating the backup.

It's also a good idea to have two backups, one kept onsite and another offsite. Having an offsite backup protects from complete data loss in the event the computer and onsite backup are lost or otherwise compromised.

While not as convenient as automated "backups", connecting and disconnecting backup drives and manually initiating backups takes very little time and effort, especially when using FFS. I have four data drives in my computer. Each data drive has a set of four backup drives (bare internal type drives) with two of each set being kept onsite in a drawer away from the computer and the other two of each set being kept in my safe deposit box at my credit union. I swap out the onsite and offsite backups no less than once a month.

I have two hot swap bays built into my computer. To backup all my data drives, I run full antivirus, antimalware, and antispyware scans (I just set them and for get them until they finish), then insert two backup drives into the hot swap bays (one could also use an external dock), wait for the computer to "see" and index them (it doesn't take long), then open two instances of FFS, select the appropriate profile for each drive, and start the update. While the updates are running, I can walk away or continue to use the computer. When both backups are finished, I close FFS, then swap out the two backup drives with the next two, rinse, and repeat. The security scans can take an hour or two to run but I spend less than one minute starting them. The updates themselves I normally can start and finish while watching the news on TV.

While most people will not need an extensive (ok, anal) backup scheme as mine (two backup drives per drive being backed up is plenty for most people), the point is manually updating backups takes very little actual time and effort but is much safer than automated ones. My actual time is less than 10 minutes per update (assuming I backup each drive daily; I don't since not all my drives receive new or changed data every day); the rest of the work is done by the computer without my help.

[kRel]

For drive-letter mapped network locations, you can tell Windows if you want those drives to be reconnected during the next logon or not.
And by running command-line "net use ..." instruction, you can tell Windows
* to mount a mapped drive by using "net use [driveletter:] [\\computername\sharename[\volume]] [/persistent:{yes | no}]", where persistent:yes remount the drive at next logon, and persistent:no does not.
* to dismount a mapped drive by using "net use [driveletter:] [delete]"

By having a batch script that mounts the backup location, then runs FFS and then dismounts the backup location, the backup location is only mounted during the FFS sync.

Thanks for the input.

I deepen and apply.

I join the request that FFS can mount the unit or drive at the beginning of the copy and at the end of the copy that can to dismount a mapped drive

you must write the batch script and then use it through the windows Schedule: Administrative Tools> Task Scheduler

If you want to get help on how to create it then the question is another. . . :)

There are many reasons why automated backups are a bad idea. To be able to automate a backup, the destination drive needs to be connected to the computer at the time the backup is to take place. That normally means the drive is connected to the computer full time, leaving the drive vulnerable to data loss from a variety of dangers, such as power surges burning up the drives, floods, fire, theft, etc. Even if a drive is dismounted, a virus could remount it.
. . . . . . . . .
. . . . . . . . .

You're absolutely right and the way you proposed are also used by me at home, but in the workplace (small-office) the solution proposed by you is not applicable.
As a result - while taking some precautions - you are forced to accept a compromise solution and reserve weekly backups for disconnected units ...

[Lady Fitzgerald]

...

There are many reasons why automated backups are a bad idea. To be able to automate a backup, the destination drive needs to be connected to the computer at the time the backup is to take place. That normally means the drive is connected to the computer full time, leaving the drive vulnerable to data loss from a variety of dangers, such as power surges burning up the drives, floods, fire, theft, etc. Even if a drive is dismounted, a virus could remount it.
. . . . . . . . .
. . . . . . . . .

You're absolutely right and the way you proposed are also used by me at home, but in the workplace (small-office) the solution proposed by you is not applicable.
As a result - while taking some precautions - you are forced to accept a compromise solution and reserve weekly backups for disconnected units ...

Why wouldn't it work for a small office?

[kRel]

...

There are many reasons why automated backups are a bad idea. To be able to automate a backup, the destination drive needs to be connected to the computer at the time the backup is to take place. That normally means the drive is connected to the computer full time, leaving the drive vulnerable to data loss from a variety of dangers, such as power surges burning up the drives, floods, fire, theft, etc. Even if a drive is dismounted, a virus could remount it.
. . . . . . . . .
. . . . . . . . .

You're absolutely right and the way you proposed are also used by me at home, but in the workplace (small-office) the solution proposed by you is not applicable.
As a result - while taking some precautions - you are forced to accept a compromise solution and reserve weekly backups for disconnected units ...

Why wouldn't it work for a small office?

Good evening . . .

I have not written that in a small office "does not work" I wrote that (daily) is not applicable. Which is different :)

In normalcy, in the evening automatically, start bailouts towards the backup unit that must be turned on and online.
If these were to be started each time, it would be a nuisance, and it could happen to forget to turn them on.
I accept the risk. In many years it never happened and at worst you need to rebuild a week's backups ...

[Lady Fitzgerald]

...
You're absolutely right and the way you proposed are also used by me at home, but in the workplace (small-office) the solution proposed by you is not applicable.
As a result - while taking some precautions - you are forced to accept a compromise solution and reserve weekly backups for disconnected units ...

Why wouldn't it work for a small office?

Good evening . . .

I have not written that in a small office "does not work" I wrote that (daily) is not applicable. Which is different :)

In normalcy, in the evening automatically, start bailouts towards the backup unit that must be turned on and online.
If these were to be started each time, it would be a nuisance, and it could happen to forget to turn them on.
I accept the risk. In many years it never happened and at worst you need to rebuild a week's backups ...

I misread your comment and apologise.

If someone wants to ensure the safety of their data, they have to assume some responsibility. Every job I ever had required me to remember to perform certain tasks every day. The same is true of most other jobs. Security programs work full time and full scans can be safely automated. However, onsite backups must be kept disconnected from power and the computer(s) except while updating a backup. Flip a switch and, when ready, start FFS. it's not rocket science but people can be given check lists to follow to help ensure they do what's needed. Even though not need for most of my jobs, I made my own since I was prone to forgetting things occasionally due to my ADHD.

A good, reasonably priced, basic paid cloud backup service can be used for an offsite site backup with the advantage that backups are updated almost continuously. The caveat here is that an onsite site backup is mandatory. The better cloud backup services will scan any data being uploaded to ensure malware is not introduced to their servers and your data is encrypted before it ever leaves your computer.

However, it may even be better for a small business to not even have an onsite backup. There are cloud backup business plans that can handle all backup needs, including rapid redeployment, georedundancy (copies of data stored in multiple servers physically separated by hundreds, if not thousands, of miles), extra security and encryption, etc. However, you will pay for those.

[CAKS]

I am probably old school, but I have a WD My Book 5TB drive for one of my backup repositories.
It is connected to my computer via USB.
The drive is ON when it is plugged in and OFF when you unplug it (from the wall outlet).
I purchased a power strip from Amazon that has a timer built-in.
The timer powers on the My Book, FFS runs the batch file each evening, and then the power strip powers the My Book off.
It has done this for over two months with no intervention required.
I retain versions and when the drive gets full, I'll just put another one in its place and keep the full one offsite.
It is not my main backup solution, but for a small investment, I have viable copies on a portable drive.
Just my $0.02 worth. Thanks.

[markusoft]

net use \\server\sharebkup /d
net use \\server\sharebkup /user:admin password

of course this only works if it's the ONLY share or you have to remap existing

net use \\server\* /d
net use \\server\sharebkup /user:admin password
FFS Batch
net use \\server\* /d
net use \\server\sharebkup /user:regularuser password


this is why a before/after script is needed, but I just resort to use SyncBack Free for the limitations of FFS
I just create a dummy source / destination for SyncBack to work with and use the scheduler and before after scripts