Ransomware resistance


RobJ

130 posts in this topic Last Reply

Recommended Posts

I have a similar (and inferior) arrangement to RobJ and bubbaQ but with Crashplan.

 

I set up a back-up share which is private and not published and set Crashplan to back up there every 3 days. Basically my rationale is if I get a ransomware attack, I should be able to detect it within that period and switch off Crashplan.

 

This isn't a horrible plan, but it wouldn't work for me. Any plan is going to have some element like this though.

 

rsync can be made to do incremental backups by hard linking to files that were unchanged, can we use this somehow to create "snapshots" of sorts in some way?

 

What I would really love is a redirected write in Samba, read from X directory, write to Y directory. If this sort of thing could be made to happen, and even writes to existing files resulted in a new version of that file at Y, then I think protecting the array from ransomware would be pretty easy. 

Link to post
  • Replies 129
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I've been giving this problem some thought, and did some experimenting. If you set a file to read-only permissions (chmod 444 file.ext), and set it to an owner other than your own userid (e.g., root),

Those are some cool ideas!  I'm thinking put a jpg on the root of every file system (call it nude.jpg? financials.jpg? but actually be a pic of a horses back end, or a lime).  In the root, it should l

A good starting point would be from @NAS s post in the Accelerator Drives thread. I would start with a "find" command and piped to exec.   The -ls parameter does a file listing of the resul

I have a similar (and inferior) arrangement to RobJ and bubbaQ but with Crashplan.

 

I set up a back-up share which is private and not published and set Crashplan to back up there every 3 days. Basically my rationale is if I get a ransomware attack, I should be able to detect it within that period and switch off Crashplan.

 

I have the same thing... I also simply keep all versions of my files.. So even if I find out about the ransomware in half a year I should be able to revert back using backups..

Link to post

I have a similar (and inferior) arrangement to RobJ and bubbaQ but with Crashplan.

 

I set up a back-up share which is private and not published and set Crashplan to back up there every 3 days. Basically my rationale is if I get a ransomware attack, I should be able to detect it within that period and switch off Crashplan.

 

I have the same thing... I also simply keep all versions of my files.. So even if I find out about the ransomware in half a year I should be able to revert back using backups..

 

You guys are exceptional though!  I suspect many users don't have *any* backups, because unRAID is working so well for them that it's a low priority, something they know they need but not as important as other things.  I'd like to see these features so automated and easy to setup, that no one has any more excuses.

Link to post

You could do it quite easily on one system also..

 

Just create a share that is not writable when mounted (give a user write access that you do not use from windows) and rsync all your other shares into that making it so that you do not overwrite..

 

 

Verzonden vanaf mijn iPhone met Tapatalk

Link to post

Remembering my old days working on RSX-11M on PDP11/45 (yeah...), the files had a version like such: file.ext;n , where n is the version number. Every time you modify a file, n increases by one. There was a special command to purge the files, leaving only the latest version. This way you could always go to the previous version, and I'm sure this would serve as a good ransomware resistance tool.

Link to post

I don't think there is anything off-the-shelf in Linux that will do this, unfortunately.  But a cron job to change permissions on files modified more than xx-days/hours ago to make them read only would work with minimum of work.  Call it a "change window" on new files.

 

CryptoFortress and progeny will encrypt any shares it finds that the workstation can get to... not just mapped drives.

 

 

Link to post

I don't think there is anything off-the-shelf in Linux that will do this, unfortunately.  But a cron job to change permissions on files modified more than xx-days/hours ago to make them read only would work with minimum of work.  Call it a "change window" on new files.

 

CryptoFortress and progeny will encrypt any shares it finds that the workstation can get to... not just mapped drives.

 

Nice... That would actually work...!  Plugin anyone ?  Preferable share based with a "change window" per share..  :-)

Link to post

Remember your exposure window will be the change window plus 2x the interval between job runs.

 

And a lot of people attach as "root" because Windoze caches credentials.... and this won't protect against root, unless you use extended attributes like "immutable."

Link to post

And a lot of people attach as "root" because Windoze caches credentials.... and this won't protect against root, unless you use extended attributes like "immutable."

You cannot attach to a share with 'root' credentials and get 'root' access.  This has been the case ever since v6 came out (cannot remember if it was also true with v5).  If it is a public share you will be able to use the 'root' username, but the file will still be accessed with 'nobody' credentials.  If it is not a public share then 'root' is not an acceptable username for connecting.
Link to post

And a lot of people attach as "root" because Windoze caches credentials.... and this won't protect against root, unless you use extended attributes like "immutable."

You cannot attach to a share with 'root' credentials and get 'root' access.  This has been the case ever since v6 came out (cannot remember if it was also true with v5).  If it is a public share you will be able to use the 'root' username, but the file will still be accessed with 'nobody' credentials.  If it is not a public share then 'root' is not an acceptable username for connecting.

 

Interesting, so this means the whole Cron Job to Read Only might work.

 

You could also add a run now function and a "unlock" that gives it write permissions... giving you better control without having to mess with command lines.

Link to post

You cannot attach to a share with 'root' credentials and get 'root' access.  This has been the case ever since v6 came out (cannot remember if it was also true with v5).

 

Same is true for unRAID v5.

Link to post
It depends on what your goals and concerns are. The major concern in this thread is that a Windows (or less likely a Mac) machine gets infected with ransomware that traverses the shares it has access to and encrypts the data on your Linux machine. If you don't allow that samba share to have write permission that ransomware running on the Windows machine can't modify the files on your Linux machine.

 

The only windows machine I have in my home is a Windows 10 VM under unRAID I access from work with RDP.

Am I safe assuming I have a strict control of the programs installed? or is possible to get infected with the port open for RDP?

 

Thankyou

Gus

 

Link to post

At the moment ransomware spreads by infecting files on local systems and file systems it can access remotely, it used to be that it would only spread on on attached filesystems (eg: mounted drives / shares).

 

This is no longer the case, it now scans for filesystems on your network and if it finds them it will try to infect them using credentials it has stolen and/or user nobody..

 

So an RDP connection should be safe at this time. With stuff like this you never have absolute certainty though. If it gets interesting enough for the guys whjo create this sh*t to utilise RDP they might at some point.. 

Link to post

If you are connecting to the pc from work via RDP and whilst remotely connected to said computer via RDP  you open an infected email attachment on the remote computer or download an infected file on the remote computer, it can still get infected with ransomeware. Can the ransomeware detect your RDP connection and travel through the RDP connection to your computer at work, no, if that is what you are asking. Will the ransomeware encrypt as many files as it can on the local computer, yes. Will it go out on the network and look for any shares that user has write permission to and encrypt them, more than likely but it depends on the variant of the cryptomalware.

Link to post

It depends on what your goals and concerns are. The major concern in this thread is that a Windows (or less likely a Mac) machine gets infected with ransomware that traverses the shares it has access to and encrypts the data on your Linux machine. If you don't allow that samba share to have write permission that ransomware running on the Windows machine can't modify the files on your Linux machine.

 

The only windows machine I have in my home is a Windows 10 VM under unRAID I access from work with RDP.

Am I safe assuming I have a strict control of the programs installed? or is possible to get infected with the port open for RDP?

 

Thankyou

Gus

 

Just to be clear, this is a VM running on unRAID that you RDP into? If so you don't have to worry about the RDP part exactly... can you access your unRAID shares from with in your Windows VM (Meaning: When you RDP into Windows, can you navigate to your SMB shares?) If yes, then it is possible that an infection in that VM could spread, if no, then I don't think you have anything to worry about... yet.

 

 

Link to post
can you access your unRAID shares from with in your Windows VM (Meaning: When you RDP into Windows, can you navigate to your SMB shares?) If yes, then it is possible that an infection in that VM could spread

 

Yes, basically is what I do. Download some files and copy to the shares.

 

In the case I got a ramsomware and it encrypts my crashplan share, the cloud copy will also be update with the encrypted files?

 

Gus

 

Link to post

 

 

can you access your unRAID shares from with in your Windows VM (Meaning: When you RDP into Windows, can you navigate to your SMB shares?) If yes, then it is possible that an infection in that VM could spread

 

Yes, basically is what I do. Download some files and copy to the shares.

 

In the case I got a ramsomware and it encrypts my crashplan share, the cloud copy will also be update with the encrypted files?

 

Gus

 

Yeah, that really bothers me. If you have automatic backups set up, then it can potentially ruin the backups as well

Link to post

Yeah, that really bothers me. If you have automatic backups set up, then it can potentially ruin the backups as well

 

The notion of a WORM share-type with an update window is not to eliminate 100% of ransomware exposure... it is to minimize the damage.  If you want 100% protection, you need to implement versioning or a backup rotation strategy like grandfather-father-son.

Link to post

 

 

can you access your unRAID shares from with in your Windows VM (Meaning: When you RDP into Windows, can you navigate to your SMB shares?) If yes, then it is possible that an infection in that VM could spread

 

Yes, basically is what I do. Download some files and copy to the shares.

 

In the case I got a ramsomware and it encrypts my crashplan share, the cloud copy will also be update with the encrypted files?

 

Gus

 

Yeah, that really bothers me. If you have automatic backups set up, then it can potentially ruin the backups as well

 

Not really... That would constitute a change to an existin file so versioning would you allow to go back to previous version.. which would be non-encrypted..

Link to post

 

 

can you access your unRAID shares from with in your Windows VM (Meaning: When you RDP into Windows, can you navigate to your SMB shares?) If yes, then it is possible that an infection in that VM could spread

 

Yes, basically is what I do. Download some files and copy to the shares.

 

In the case I got a ramsomware and it encrypts my crashplan share, the cloud copy will also be update with the encrypted files?

 

Gus

 

Yeah, that really bothers me. If you have automatic backups set up, then it can potentially ruin the backups as well

 

Not really... That would constitute a change to an existin file so versioning would you allow to go back to previous version.. which would be non-encrypted..

 

Not every backup has versioning... which I think is very important for the reason you pointed out.

 

Based on this thread I have two main points now:

 

1) Make sure any auto Backups have versioning.

2) Lock of the shares you can by making the SMB share Read-Only. When you need to do a write unlock the shares by making them Read Write first or do it via command line.  IF you unlocked it, re-lock it afterword.

Link to post

Yes.. which is one of the main reasons I use it... It also protects against stupidity..

 

Since you can set it up to have unlimited versioning and never to delete any files, you can basically restory anything you accidentally delete..

Link to post

I am testing with a couple different configurations.

 

I set up the crashplan docker on both of my servers and have one backing up to the other. Versioning is on and it never deletes files. The share containing the crashplan data is not exported and is accessible only through command line. The only thing I don't like about it is that the backed up files are only available through crashplan. I read some stories where people were complaining that they were unable to restore from their backups even though everything looked fine.

 

I also set up a father grandfather scheme. Rsync creates a backup on the backup server from the main server once a week (only the most critical data like family pictures). And then it syncs that folder to a different share on the same machine with a one week delay. That second share is not exported at all. Only available through command line on the backup server.

 

So if I get ransomware and my main unraid server is encrypted,  I have about one to two weeks to recover from the rsync backups. With crashplan, I should be protected indefinitely, as long as the backups are still valid.

 

By the way, I'm only protecting my crucial documents this way, and not the movies or tv shows I have. Since the movies and tv shows account for 90-95% of my storage, the redundancy in these backup schemes are no big deal (about 150GB duplicated)

 

Link to post

Another idea would be a new security permission level: Read & Append

Users could read files, and add uniquely named files, but not overwrite or delete existing files.

This would be good for our media shares that are mostly cold storage, as well as being a good fight against malware.

One would stay logged in at this level for day to day activity, then switch to a higher level login for cleaning and file maintenance.

This would be great, perfect to secure Movies and TV shows from ransomeware.

Link to post

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.