Ransomware Resistance Methods

From unRAID
Jump to: navigation, search

Work in progress, incomplete yet! Perhaps only 30% done so far?

My apologies, I have a terrible time ever finishing anything, especially if I've been away from it for awhile.

This page is an attempt to compile the ideas from the Ransomware resistance thread into one place, where users can more easily compare them, and determine which methods better fit their needs.

Any shared data resource requires security controls, especially now-a-days with the rampant ransomware attacks. No data server should be planned without serious consideration for its defenses. I believe the three most important factors for a defense from ransomware are access control, backups, and staying updated, the first 2 being the most important.
  • Access control - "what they can't touch, they can't hurt". Check all share settings and limit them to read only as much as possible. When you *have* to provide write access, limit it to secure and authenticated users, and as far as you can, limit their write access time, as short as absolutely necessary.
  • Backups - need we say more? A server is not a backup, extra copies in separate locations is a backup, and one of those copies should be offsite, or at least well separated. Then make sure the location of the backups is as inaccessible as you can make it.
  • Stay updated - good security is not about being perfectly protected, that's not possible, but you *can* make a 'best effort' to keep your defenses up. You do that by making sure you have the latest security fixes, and by staying informed.

I think it's time to create a list of all our ideas, and see which can be presented as feature requests. There have been so many ideas here, and some are quite good, but we'll have to see what LimeTech implements. I decided to go back through and collect what seemed like the best ideas (my apologies to anyone that feels left out), organize them somewhat and add a few comments. Hopefully the ideas here will help LimeTech plan future features.

Any discussion or suggestions or new ideas should be in the Ransomware resistance thread, but could also be in the Talk page for this wiki page.

  1. Share mode with power user
    • Derived from: here
    • Description: This would be a new share mode where normal share access is set to read-only, but with a new share setting for a user name (the share's power user). Once logged in and authenticated, this user has full privileges for this share, can read, write, delete, and rename. A desired enhancement is to make all such logins time-limited, configurable amount of time, perhaps one hour default.
    • Exposure: only from the power user's machine, and only while the power user remains logged in
    • Status: requires changes by LimeTech to add this new share mode
    • Typical usage: provides safe read-only access to other machines, but allows for one power user to occasionally log in to do anything necessary. On the server, access is unrestricted so the server administrator and tools such as Plex have full read/write control. Plex on a different machine would only have read-only access. Users can browse and view but not delete or change directly. They could however use a client (such as a Plex client) to do those things, if the client directs the server to do them. This should handle many users' needs.
  2. All shares read-only except one temp share, transfers are manual
    • Derived from: here
    • Description: User sets all but one User Share to read-only, sets a Temp share to read/write, then uses mc or other transfer method to manually move the files from temp share to desired share.
    • Exposure: anything still on temp share; this could be a problem since it depends completely on that user
    • Status: can be done by any user now
    • Typical usage: provides safe read-only access to other machines. This method is best when there is a controlling user who will manage the whole system. Guest users can be directed to add new files to the temp share, where the managing user will move them to their desired destination. Its primary advantage is that it can be done now, no new features needed.
  3. Backup software with versioning
    • Description: User sets up backup software on unRAID server to schedule backups to inaccessible locations. The backup software will not be effective if it does not support versioning, as the encrypted files will overwrite the backup. The big advantage is that this works for shares that need to be read/write.
    • Exposure: anything that hasn't been backed up yet, so depends on how often the backup runs
    • Status: can be done by any user now
    • Typical usage: every one needs a backup methodology, so if backup software is already installed, then it hopefully has modes of behavior that accommodate ransomware protection. Typically there are ongoing fees for this though. A big advantage is that this can work where read/write access is required.
  4. File system with built-in snapshots
    • Description: User sets up all shares on file systems with snapshots, such as BTRFS or ZFS. Unfortunately both have major downsides, BTRFS is not trusted sufficiently and ZFS requires considerable technical expertise and is not currently supported in an unRAID array.
    • Exposure: unknown; may be a good solution in the future
    • Status: can be done by more technical users now
    • Typical usage: an alternative to backup software for more technical users. Can work where read/write access is required.
  5. Malware detections - canary methods
    • Derived from: mentioned first here, then here, here, and here
    • Description: Either built-in or by plugin, detects changes or deletions of 'canary' files and may detect files associated with malware behavior, triggers alarms and user notifications and actions, such as array stop or system power down or share 'locked'. May monitor file activity for suspicious actions, such as modifications to 10% of all files, etc.
    • Exposure: may allow some files to be damaged before it can act to stop the malware
    • Status: needs a plugin developed, or changes by LimeTech
    • Typical usage: if malware detection features are developed, then this should be used by ALL unRAID users, first to detect an attack and raise alarms, then to respond to it.
  6. Avoid or restrict usage of boot GUI Firefox
    • Derived from: here
    • Description: The built-in browser is certainly helpful, but it should be restricted to local usage only, e.g the unRAID management pages. Unknown how risky it is, but it seems like a really bad idea to surf the web as the root user.
    • Exposure: it's a popular browser on the Internet as root user! However, it's a limited target, running on a relatively well-patched and slimmed Linux system.
    • Status: can be done by any user now
    • Typical usage: this is a matter of education, to make sure that users know the risks of using the built-in Firefox browser outside their local network
  7. Keep server off as much as possible
    • Description: A simple idea, but limiting time on the network limits the window of opportunity to be attacked. Many users need it on at all times, so this method is not for them. It's for users who are primarily using their unRAID server for occasional archiving, only need to turn it on for backup jobs.
    • Exposure: exposed only when server is turned on
    • Status: can be done by any user now
    • Typical usage: not for most users, only for those who can get away with turning their server on very infrequently. While turned on, server is fully exposed, unless other methods are in play.

  1. Template
    • Derived from: [ here]
    • Description:
    • Exposure:
    • Status: requires changes by LimeTech
    • Status: can be done by any user now
    • Typical usage: