Alistair Mann al at pectw.net
Thu Jun 17 10:58:25 UTC 2021

My solution was to write a FUSE filesystem for the backup server whereby 
successive changes to a file result in a linkedlist-like chain of files 
with the latest link being the latest copy of the file. Deletes are 
handled similarly with the latest link indicating the deletion but not 
otherwise touching previous copies.

To the live server it looks like any other network share.

3 min demo rolling back a ransomware attack to the microsecond it 
happened: https://youtu.be/VsBAKeOQh78.

Ideally, disks would use their spare capacity to implement something 
like this in firmware, with final deletion requiring proof of physical 
presence. I suspect too many sticky fingers for that now.
Alistair Mann

On 17/06/2021 10:06, Marco van Beek via GLLUG wrote:
> We have a different methodology where the live server initiated the 
> backup, but once each set is completed completed sets a flag on the 
> backup server and the backup server then takes a copy using hard links, 
> so that allows us to have a whole bunch of historical copies that cannot 
> be accessed via the live server. Also, the live server only has a 
> restricted shell on the backup server so can only run a limited set of 
> commands, and is chrooted to it's own home directory.
> Pros and cons to both methods, but both have the same end result as far 
> as ransomware access is concerned.
> Regards,
> Marco
> On 16/06/2021 18:40, John Winters via GLLUG wrote:
>> On the backups front, I have long felt that for secure backups it is 
>> essential that the backups are driven by the backup server.  The 
>> backup server establishes a connection to the live server and backs up 
>> what it is configured to back up.  The live server must have no access 
>> to the backup server, nor means to establish a connection to it.
>> If your backups are driven and controlled from your live server, then 
>> as soon as it is compromised the attacker has the option to modify 
>> what backups happen, or even prevent them entirely.  If the live 
>> server has some kind of write access to the backup server then they 
>> can go on and compromise all your existing backups too.
>> If the backup server is the one initiating the backup but runs no 
>> externally accessible services, then it does a backup when it is 
>> configured to do a backup.  If the live server has been compromised to 
>> the point where the backup server can't, then it can report the fact. 
>> No amount of corrupting the files on the live server will affect those 
>> on the backup server.
>> Of course you still need a suitable cycle of backups so you can go 
>> back as far as is necessary to recover.
>> I have two backup servers in different locations which do fairly 
>> comprehensive backups each night.  When they're not doing that, 
>> they're switched off which makes them even harder to crack into.
>> John

More information about the GLLUG mailing list