My Attempt to Protect from Ransomware

Background

About a year ago, a local newspaper published an article regarding Ransomware.  It was the first time I had heard of this scam and intrusion.  It alarmed me!  The business was able to restore their data because they had daily off-site backups; most victims weren't as fortunate.

With that in mind, I decided it was high-time to get my backups in order and methodical.

This will be a series of postings detailing what I've done, and what I'm going to do regarding this.

First Steps

Backups

Except for a single laptop, all of my various systems are Ubuntu or Raspbian; all a derivitive of linux. So, naturally, my backup plan was going to involve 'tar', 'gzip'.  The backups were going to be on USB Hard Drive devices.

I have a lot of data, as well as a lot of programs that I want to retain permanent access to, and not lose to Ransomware.  

After a lot of research, I decided I was going to implement:

• Daily Backups.  These would occur on Sunday Morning 00:30, through Friday morning 00:30.  These would be differential in nature, meaning the backup would be for any file that had changed since the last Weekly Backup on Saturday. 
• Weekly Backups.  These would be a full backup of the system.
• Monthly Backups.  Same criteria as Weekly Backups - full backup of the system.
• Image Backups: Entails bringing the system down and rebooting into FileZilla, then producing two (2) images: one of the root file system '/', and the other of home '/home'.  Performed monthly, this is an important step, as it lets me also have the ability to restore my 'virtualbox' system, which has a Windows instance on it.  Using images, I'm able to restore to a new hard drive or partition and Windows doesn't complain - it doesn't see the new hard drive or restore as being different, so it runs correctly.  This is the only way I've found to do this without Windows refusing to run.
• Backups of Backups
• Since I still have vulnerabilities associated with times the filesystems are either mounted or can be mounted if root password is obtained, the above backups can still be destroyed by someone malicious.  In order to prevent this, I have a separate BackupsOfBackups Raspberry Pi that is not connected to any network, that has it's own 5TB USB hard drive attached to it.  Once a week, I manually disconnect the USB connection from my Weekly and Monthly backups, and manually connect  them to my BackupsOfBackups Raspberry Pi, where I do a copy to the backup filesystem on that BackupsOfBackups Raspberry Pi.  I do not run any software that is located on any of the primary backup filesystems; only software that I installed on the Raspberry Pi.  I do not connect this BackupsOfBackups Raspberry Pi to the internet, even to get updates - it stays as it was when I created it.  I only use Raspbian OS as distributed from the Raspberry organization.  By doing this in this way, I see no way for a malicious person to destroy the filesystem located on the BackupsOfBackups Raspberry Pi.
• Criteria:
•  Backups would utilize 'tar' and 'gzip', as well as 'exclusion files' for tar.  For instance, I excluded the '/tmp' directory.
• Each backup type (e.g., Daily) were to be kept on their own USB hard drives.  This means at least four (4) separate USB hard drives are dedicated to this approach.  This is a personal choice; your choice could be to go to a single USB hard drive instead.
• USB hard drives would be unmounted and mains unplugged in the morning and reattached in the evening in order to shorten the window for direct attack; this however would not alleviate an attack that managed to place executables onto my system that was stored to run any time a partition was mounted.
• An automated backup script would be created to run each morning at 00:30.  This would mount the necessary hard drive partition, then perform the correct backup based on the day and date (end of month) for the system.
• Notes
• All filesystems are owned by root, and permissions set to 400, with directories set to 500.  This doesn't protect if someone has root password!
• The hard drives would be unmounted except when needed for the backup, and also disconnected from mains electrical, in order to preclude someone malicious that had somehow gained root access to mount those filesystems.  I have a multi-strip that has individual switches on it for each outlet that is very useful for this mains isolation.
• The backups are automated in a 'bash' shell script that detects the day (when to do Daily vs Weekly) and the date (month end).  It also mounts the appropriate partition at the start, and unmounts it at the end, and makes status log entries into /var/log/Backup log-files.
• If the mount fails, then the backup is aborted and an error created, as my '/' filesystem isn't large enough to store the backup.
• The 'bash' shell script is run via root's cron, every day at 00:30.
• An email is sent to me showing pass/fail.

Future

I sometimes have forgotten to manually turn on the mains switch to the USB hard drive associated with that morning's backup, resulting in the backup aborting.  I also have a larger than desired window of opportunity for someone to get into my system, as I typically turn on the mains switch for the drive around 9:00 PM, then back off around 6:00 AM (unless the backup is still running!).  I am in the process of installing a relay board (for mains isolation) that will be controlled by a Raspberry Pi 3.  This will utilize node.js to receive API commands from the main system backup 'bash' shell script, instructing the Raspberry Pi to turn on the appropriate mains switch relay at the start, then back off at the completion/abor and unmount completing.

I have purchased the relay board, and the Raspberry Pi, so am now in the process of creating a driver board in order to limit the current the Raspberry Pi was going to have to sink.  Looking at software CAD programs that will produce a perfboard (or similar) drawing output.

I'll create a new blog entry on the development of the driver board and the node.js software running on the Rapberry Pi, once I get this worked out.