Is UnRaid OS RansomWare attack free?


slipstream

Recommended Posts

Hi All,

I just learned QNap NAS users recently got hit with a ransomware attack.  All their data got encrypted and now they have to pay in Bitcoin to get their data back.  I have all of my shares set to PRIVATE. Is that safety measure strong enough to protect my data from any possible ransomware attack directed to the UnRaid OS in the future?  Should I also disable the FTP and SSH features in my UnRaid OS for extra security?  Any opinions welcome.

Edited by slipstream
Link to comment

As part of the above, I set shares that are almost never accessed to not be exported (so they are not accessible or visible on the local network).  Then I configure shares for items such as media that are accessed frequently for reading but rarely for writing to be read only.  For both of these I only modify the settings as needed of access or updates on a temporary basis.  This prioritises security above convenience, but it minimises the time that a potential rogue device on the network could possibly have access.  The only shares that I have enabled for writing are not used for critical data, and only for short term storage. 

 

On top of that I have a second backup server, which is powered off and therefore completely inaccessible for more than 99% of the time (that is, any time except when I am updating those backups). I accept that not everyone has the luxury of a second complete backup, but it is vital to have additional backups of critical data on storage which is completely independent of your Unraid server.  The same would apply to any other network connected storage system.

Link to comment

As someone whose full time job is InfoSec for a multinational, I need to reply here.

Saying not to expose stuff to the Internet is obvious but it doesn't remove the problem.  The biggest concern I have with unRAID is a supply chain attack, and unRAID is popular enough now that e-Crime actors will already be looking at targeting the platform.

The question is this:  who validates all the plugins etc to make sure they don't have malicious code in them or the ability to subsequently download malicious payloads?  Never mind Docker or VMs, those are the responsibility of the end user - period.   The risk is going to come from the commonly used plugins that everyone uses:

  • Unassigned Devices
  • Nvidia
  • Fix Common Problems
  • Nerd Tools
  • Preclear disks
  • etc

So, what's Limetech's response?  Better to get ahead of this before it actually happens.   if the risk lies with the end user for 3rd party plugins the link to this in customer agreements need to be pointed out.

Edited by Kaldek
  • Like 2
Link to comment
8 hours ago, Kaldek said:

As someone whose full time job is InfoSec for a multinational, I need to reply here.

Saying not to expose stuff to the Internet is obvious but it doesn't remove the problem.  The biggest concern I have with unRAID is a supply chain attack, and unRAID is popular enough now that e-Crime actors will already be looking at targeting the platform.

The question is this:  who validates all the plugins etc to make sure they don't have malicious code in them or the ability to subsequently download malicious payloads?  Never mind Docker or VMs, those are the responsibility of the end user - period.   The risk is going to come from the commonly used plugins that everyone uses:

  • Unassigned Devices
  • Nvidia
  • Fix Common Problems
  • Nerd Tools
  • Preclear disks
  • etc

So, what's Limetech's response?  Better to get ahead of this before it actually happens.   if the risk lies with the end user for 3rd party plugins the link to this in customer agreements need to be pointed out.

 

Kaldek is correct that the real attack vector isn't going to be attacks from the internet but rather attacks from malicious code hidden within existing plugins.

 

Now thankfully most of these plugins are small python that can be easily checked but some checks are going to be needed somewhere to stop malicious changes being made.

 

And probably an education effort (even if it's just a warning banner) saying Dockers and VMs should

 

1) only come from trusted sources

2) only grant access to the folders they need access to and absolutely NOTHING else. 

Link to comment

My response, not the official Limetech response.  Every single user of CA has had to acknowledge two distinct popups regarding applications prior to any installation being allowed.  A general one and also another specifically geared towards plugins, which link to https://forums.unraid.net/topic/87144-ca-application-policies-notes/?tab=comments#comment-809115 and https://forums.unraid.net/topic/87144-ca-application-policies-notes/?tab=comments#comment-817555 respectively, which also detail some (but nowhere near all) of the security procedures in place.

 

The lists within CA are not just a compendium of "applications at large".  They are moderated, and constantly being reviewed.  Great pains are also taken to have the ability to notify users of any malicious software installed, either through FCP or CA's own emergency notification system (opt-in).

 

Now, if you do decide to go and install an app that is outside of CA's control, then you are on your own.

 

But to directly answer your question, all plugins and many containers are code reviewed when being added into CA.  ALL plugins MUST be open source except in exceptional circumstances.   Provisions exist for removal / notification to the user if anything malicious happens after the fact.

 

(To be quite honest though, I would worry far far more about a docker container being installed via the command line (or a dockerHub search) that's not listed within CA rather than a plugin.  eg: How many examples are there already of mining software being embedded in a random container on dockerHub?)

  • Like 3
  • Thanks 2
Link to comment
On 5/6/2021 at 3:30 AM, Squid said:

My response, not the official Limetech response.  Every single user of CA has had to acknowledge two distinct popups regarding applications prior to any installation being allowed.  A general one and also another specifically geared towards plugins, which link to https://forums.unraid.net/topic/87144-ca-application-policies-notes/?tab=comments#comment-809115 and https://forums.unraid.net/topic/87144-ca-application-policies-notes/?tab=comments#comment-817555 respectively, which also detail some (but nowhere near all) of the security procedures in place.

 


Perhaps the better question is whether Limetech are aware they are actively being probed to find a way in.  It happened to Solarwinds, it can happen here.  It's just way too easy to do this stuff and is asymmetric warfare.  We get one chance to detect the breach whilst the attacker has unlimited time to perfect it by finding even the remotest weakness and using that as the beachhead.

Edited by Kaldek
Link to comment

There is no 100% safety, disconnect your internet and get 100% safety.

Every entity in your Network can be compromised.

 

At least the base installation of unraid should be safe.

Everything you add could cause problems and is a risk if you change something in unraid to a certain amount of degree.

 

Safety starts with the person sitting infront and using the system.

  • Thanks 1
Link to comment

Thank you to all for your posts.  Hopefully, what I have learned in this thread will bulletproof my UnRaid data from any possible future ransomware attack and not have to go through the same hell the poor QNap user shown in the YouTube video below has gone through:

 

 

 

 

 

Link to comment
  • 5 weeks later...
  • 1 year later...
9 minutes ago, sannitig said:

Why not just say, don't build an unraid server. There, problem solved.

And PC users should never install WIndows, because, gasp, they keep getting hit by ransomware.

 

Not sure what your point is.  No Internet-connected OS (and Unraid is not even a full Linux OS) is totally bulletproof and some responsibility will always be with the user to keep their data safe through good practices.

  • Upvote 1
Link to comment
On 4/7/2023 at 8:23 PM, sannitig said:

wtf is the point of a server then? Don't have users with R/W, don't expose it to the internet.

 

Why not just say, don't build an unraid server. There, problem solved.

The problem is any permissions you allow increase attack surface. If a user with full R/W access to a share has their PC compromised and a ransomware application uses that R/W access to encrypt the files, the vulnerability wasn't the fault of the file sharing, but the permissions given to the user.

Properly segregating user access to shares is not very complicated and its totally possible to do so while mitigating the possible attack surface sufficiently. A bunch of static install media used for making bootable media or PXE boot environments? Don't exactly need R/W access to that share. But what about the logging you ask? Excellent question - by using dynamic mapping you can create a per-client read/write directory automatically. If ransomware wishes to encrypt some installer logs fine, we can just delete those and move on with our day.

Similarly, you can set up per-user shares fairly easily as well, and have those be read/write. Taking active snapshots of user directories has much less impact than taking active snapshots of the entire filesystem. For example, let's take a look at some of my data sets -- I have an archive of some "gold" images for specific hardware. Each of these images is quite large, and I do have them backed up elsewhere. The total size of these images is around 10tb. By having that entire share read only for everyone except local root access, I've reduced the need/want to snapshot those images ever. I've got an off-site backup should I need it. On the flip side, I have samba set up to point each Wireguard user at a different "Personal Folder" using the IP information for the wireguard client. There's less than 100gb of data across all users in these read/write personal folders. I can afford to take incremental snapshots of these directories and rapidly recover should any of the clients get compromised. Not to mention, since the folder is per-user, only one user would be affected by such an attack.

Edited by Xaero
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.