Setting Permissions on Private Folders

My Cloud OS 3 Personal & Network Attached Storage My Cloud
1

Just got the 2TB MC and working on the setup. I see that the default is to save to a SmartWare folder that is marked public. I have set up a password for the default Admin. Now 2 PCs use SmartWare to backup their C: to the SmartWare folder.

If I would change the SmartWare folder from public to private, I see the option is given to set the access level of Admin from Write, to Read Only, to No Access. If this works like Windows networking, then setting to No Access or Read Only could hinder the backup from occurring any more – is that what happens? Can the permission be reset from the Dashboard, so as to regain control of the folder? Or, is it like knocking out the tab on a floppy disk: what’s done is done?

I am trying to determine how the MC folder permissions work, because I am thinking it may make sense to create a private folder to which the permission has been set to No Access, as a means of hindering ransomware crooks from encrypting the data on it. Periodically the data in the Public folder could be copied to that private folder by means of internal backup function. But in that case, can a backup even be made to that private “No Access” folder? Do you have to set the permission to Write in order to make the backup, then set it to No Access after the writing is done? And can the Dashboard later change it back to Read Only, so as to be able to recover the data when it may become needed?

Could start doing experiments, but has anyone already found out what happens when resetting permissions on MC in the manner described?

Would such use of a private folder with limited permissions, help in foiling ransomware to some extent (even if not as good as having an offline backup – which is a nuisance to connect and disconnect USB). Thank you.

2

If you change the Smartware folder permissions you will have to access the Smartware program on each PC and enter in the username and password. Don’t know if you have to unlink then relink the Smartware My Cloud directory location though as when I set the Smartware My Cloud folder to private I did so before setting up Smartlware on the client computers. Check the Smartware User Manual (http://www.wdc.com/wdproducts/wdsmartware/um.asp)if you haven’t already to see if anything is mentioned in there.

The problem with ransomware attacks is that they may use any credentials already entered on the computer to access a NAS drive or mapped Share/folder. As such if any computer has accessed a Private Share on the My Cloud its possible the ransomware will have access to it, especially if the Private Share is mapped to that computer.

A better way to handle ransomware is to avoid having it infect your computer(s) in the first place. It also helps to backup the My Cloud to an external USB hard drive that way one can restore or access any backup content if hit by a ransomware attack. Obviously one has to keep that USB drive DISCONNECTED from the My Cloud when not backing up otherwise it will be infected right along with the My Cloud if ransomware gets loose on the local network.

3

The MC device seems to be its own little server – quite a bargain at the price – that uses some proprietary OS. In theory, it could be set up so that only an authorized user of the Dashboard had the ability to relax permissions – which could give the MC device a measure of insulation against attacks that may have cracked the client PCs running the SmartWare clients. In other words, the bad actors may breach a PC but that does not mean they should be able to hack the MC server without further effort. The PCs may have hidden somewhere the password they need to run backups – but if the backup is to a Public folder then there is effectively no security there – and hence nothing hidden for the hacker to take advantage of, since there is “no key to an open door”. Of course they can overwrite the public backups with encrypted backups, or delete the public backups – but if the MC server itself is not breached, then private folders accessible only to the Admin of the MC server, should still be safe.

If that plan worked you might still have to manually log in and operate the Dashboard to run periodic private backups in the capacity of Admin of the MC server. But that could be done from your desktop, without plugging and unplugging hardware cords. If I were designing the MC server, I would enable it to work that way. Whether it can or not, that’s what I was trying to determine by means of this discussion topic.

In fact, I would go further and design the MC so that non-destructive scheduled incremental backups could occur to a Read-Only folder, without even any need to log in as Admin to initiate. Since that behavior would be set in the hardware, hackers would not be able to disrupt it.

For good measure, to destructively erase or alter the saved contents of this designated backup folder you might have to physically push a “red button” on the MC case. When the MC drive gets near full, it could send an email telling you to push the button so the secured folder can be cleared and re-built from scratch. You would only push the button, after seeing that your PCs have not been encrypted by ransomware.

Ah, buttons – Steve Jobs hated them (probably because he had to pay for them) so instead he put every control into software, no matter how inscrutable that makes Apple devices to the user. Well-functioning buttons can be a great convenience decidedly worth the extra manufacturing cost. If a 25-cent button can foil ransomware, it could be worth the cost (?)

Otherwise, your only current option is to manually connect and disconnect a USB external drive to run backups on it. Basically, the jerks who write ransomware thus force everyone to return to the olden days of “backup to floppy disk” – i.e., to waste time handling offline USB drives as the modern bigger substitute for floppy disks (or tape cassettes). The further annoying downside being: since backup to offline USB drives requires manual intervention, backups may not happen so reliably. That’s a serious problem for mission-critical applications like healthcare.

4

It’s running a version of Linux; either Debian for V4 firmware, or Busybox for V2 firmware.

The file server is Samba.

It ‘could’ do a lot of things. But it is basically a file server, and clients connected to that server have access rights. That’s good if you want programs to be able to use it transparently like any other disk connected to the computer. That’s bad if one of those computers is infected with malware that has the access rights of the user currently logged in to the computer; there’s no need for the malware to ‘hack’ the MyCloud, it just accesses the file server like any client program.

That’s essentially how it already works; only the admin user can change user access rights on Shares (apart from the Public share, which cannot be changed).

At the Linux file system level, files created by clients have chown ownership of nobody:share. If you SSH in as root and create files, they have ownership of root:root, and cannot be overwritten by file server clients; if you want them to be modifiable by FS clients, you have to change the ownership. I do this when I write scripts to manipulate my media library with scripting running on the MyCloud, rather than running on a client PC (either Linux or cygwin on a PC). Running scripts locally is much, much faster than as a client. You just have to remember to change the ownership. I really ought to create an SSH user to run these scripts, and give that user the correct ownership settings so it creates files with the correct owenership…

As I said, it’s a Linux box. If you want to create your own secure backup system, you’re quite free to do so. Since it’s Linux, the entire codebase is available to download, due to GPL. There are a number of threads discussing building of the OS, adding apps, or replacing the OS with ‘clean’ Debian.

If you want to make suggestions, the best place for them is the Cloud Ideas forum, which WD do seem to monitor.

Just to be clear, this is a user forum, not WD Support; WD staff make rare appearances.

5

If you’re running mission-critical systems like healthcare, you should not be using a consumer device like a MyCloud. You should also have in place very capable firewalls, and have robust operating procedures to prevent auto-running of attachments. And have a layered backup system, and business continuity plans. You would be well-advised to consider an entirely air-gapped computer system for certain functions.

6

The My Cloud is a network attached storage device (NAS).

The OS used by the My Cloud is Linux. One can download the GPL versions of the My Cloud firmware from the My Cloud support site (https://support.wdc.com/product.aspx?ID=904) download section and modify the firmware to suit their needs or fix security vulnerabilities.

If a local computer is compromised by ransomware than the chances are good every other network device INCLUDING the My Cloud may be potentially compromised. If one accesses a Private Share on the My Cloud then potentially that username/password is saved within the computer OS. This means the ransomware may be able to access a Private Share.

One should not be using the single bay My Cloud units (the general topic of this subforum) for mission critical applications, especially in sectors like Healthcare where there are various government regulations that mandate record keeping. The single bay My Cloud units are consumer grade, not enterprise grade, devices designed for the average Joe home consumer or small home office type of user. While there is some level of security that can be enabled within the My Cloud to limit (or try to limit) access to the data stored on the My Cloud. A hacker, given enough time and access to the local network could exploit various methods to gain full access to the My Cloud. If one has physical access to the My Cloud enclosure they can simply pull the hard drive from the enclosure and access all the contents on it since there is no encryption of the hard drive or the data contained on it.

Security is a multi layered affair. If one is backing up mission critical data they should have a backup plan in place that includes multiple backups, including storing a set of backups in offsite locations. No matter how much security you have in place the human is always the weakest link.

If one is worried about ransomware they should educate themselves and any users who access their local network. They should have multiple layers of security in place. This includes locking down the local computer, segmenting the local network, restricting access to the network and any NAS devices, etc. on that local network. They should have backups that are stored unconnected to the local network. The fact is that any NAS you can access on the local network, regardless if that NAS is using password protection, can potentially be infected by ransomware.

7

Referring now to the recent 2 posts by very attentive experts, which provide valuable info about the OS used by MC.

The application of the particular device here is a home network. Prior reference to health care was just an observation in connection with the severity of the problem in general; it would be nice if no one had to worry about such things whether in home or business networks.

Certainly there are ways to defeat many kinds of security plans, including even the “air gap” method of offline backup. The bad actor can, e.g., use a first-day exploit with a time delay so that offline backup files may become infected before the hazard becomes noticed by anyone in the world. Hence even the most cautious may fall victim to the extent that some recent files may be unrecoverable – even those on the most “safe” external-backup USB drives. Hence it’s a bad problem for everyone – and especially for healthcare and the like – no matter how vigilant one may be.

One can’t expect million-buck results from a hundred-buck device, but I do put it out there that a few more buttons might be nice; even at the risk of challenging the Jobs mystique. A hardware switch such as a button is not going to be flipped by a hacker online. A burglar could do it, but it’s not burglars that are the principal current source of ransomware (they may steal your hard drive and sell it at a flea market).

I would be interested to see if there is a principled technical objection to the concept that a hardware button on a NAS device, that had to be activated on-site by hand in order to initiate a destructive erasure, could help to protect against ransomware.

To put a finer point on it: the NAS I suggest, would default to work like a CD – you can write as much as you want, but you cannot erase or modify what has been written. Only after you push the red button by hand on-site, is the NAS able to erase protected backup files (in order to free that storage space for re-use).

Imagine your backup system was in fact a giant-size single-write CD on a PC. The CD might be loaded in an internal drive and connected all the time. The PC with the CD drive gets infected. No matter how skilled the hackers, how are they going to encrypt the data that was already written to the CD? You would go for coffee at 10 AM and come back to your PC to find a CD with good data written up to the time of your coffee break, and bad data after that.

Basically what I am suggesting is that some NAS hardware might be designed to emulate such a CD, by means of the “red button”. You could still lose the most-recent files from the time of infection after the coffee break at 10 AM; but the great bulk of backed-up data from before 10AM would be recoverable (at little cost or effort). You would lose only the minimum amount of data possible under the bad circumstance of having been hacked at 10 AM.

I can foresee some objection that the file directory could be a weak link. Even if the older data is still OK on the “CD”, if the CD’s directory table were subsequently corrupted by a bad actor, so as to become unreadable, then the prior good data may no longer be possible to locate on the CD. Hence, might have to guard against that by storing periodic backup copies of the file directory – to permit going back in time until a readable directory can be found.