Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm not talking about EFS or Bitlocker here.

I'm asking if there's a way to prevent files from being encrypted. I'm referring to some extent to ransomware, but specifically I want the following scenario:

  • Windows File server w/ shares (on the E: drive)

I want a way to tell the above server "don't allow files on the E: drive to ever be encrypted by anyone or any software/process."

I can't find any way to do this at the NTFS level, short of "read" access. Modify access allows files to be encrypted.

I've searched around online but get a bunch of EFS/bitlocker/ransomware links that have nothing to do with my question at hand.

So fellow experts. Any way to do the above in bold? I'm not asking about ways to prevent ransomware, etc. The bolded area is specifically what I'm after.

share|improve this question
11  
How do you suppose that the server detects that the write by the client is malicious in nature? After all, at least from what I know, ransomware in particular doesn't use system functions for the encryption. – Sven Mar 8 at 17:29
1  
@Sven - I knew it was a very long shot. I was hoping there was some hidden ACL or something I had never heard of. I ain't too proud to beg. :) – TheCleaner Mar 8 at 20:53
    
Assuming the Crypto-locker does not perform multi-pass encryption then would you be able to save a copy of the file to a different location prior to overwriting it? In this case you would simply need double the storage and hope that the Crypto-locker bad guys don't read my comment and implement multi-pass encryption :). This also assumes that multiple users didn't get the virus and performed a distributed multi-pass encryption. – MonkeyZeus Mar 8 at 21:50
    
Ah yes, if only malware would nicely tell the OS "Hello, I'm malware!" and then you could set up rules so malware could not access anything but other programs could. – immibis Mar 9 at 1:15

In short: no.

As you said, if you allow users to have write access, then they can encrypt data. I couldn't conceive of a way that an operating system or filesystem could possibly even start to detect and prevent the many types of encryption that are out there.

It's a hard problem, though, and I expect OS vendors are devoting significant efforts towards rendering Cryptolocker et. al. less destructive than they currently are.

Until then, maintaining as many different types of backups as possible and ensuring that those backups can be restored reliably and quickly will be the best protection.

share|improve this answer
    
I can. write() errors out if it looks like random bits. But ... – joshudson Mar 8 at 21:42
5  
@joshudson Every good compression algorithm will produce output that look like random bits. – kasperd Mar 8 at 23:09
    
I think you can tell the difference between compressed and encrypted but you can't tell the difference between encrypted and noise, and sometimes you really do need to store noise. – joshudson Mar 8 at 23:10
    
@joshudson The only way to distinguish a compressed file from an encrypted one would be to try to decompress it. – immibis Mar 9 at 1:16
1  
@joshudson: So encryption program compresses its encrypted data, then writes it out. Or alternatively, encodes the encrypted data in base64 or some word code or something else with low entropy. – Nate Eldredge Mar 9 at 3:17

Yes, but also no

This is one of those weird cases where it's literally impossible to prevent every single way of doing something.

You can prevent processes like Bitlocker, Truecrypt, and other legitimate encryption programs from accessing the share. Most of the time this is done through Group Policies (Bitlocker comes to mind here) or specific 'all in one' software packages (Look at Kaseya, Labtech, or NAble).

Is it easy?

Lord no. You would have to script a response procedure for each separate encryption program. And, you would have to do so for each new program that comes on the market. It would be time intensive and painful and still only cover maybe 50% of situations. I've scripted with both Labtech and N-Able, and no it is not quick and easy to do.

Wait, you also said no?

That's right, also no. No, because most ransom ware programs aren't using an encryption program. They are just opening specific files in something akin to a text editor and changing the values according to a hash they have generated. You expressly can't stop this type of behavior unless you deny modify access to the share.

So, is it worth it?

Nope. You can probably block legitimate and helpful encryptors, but the dangerous ones are likely to still get through.


A noteworthy edit

While the actual question is handled above, what I believe the intent of the question is can be summed up a little better. Having just had another run in with a nice crypto locker today, I got a refresher for my perspective on the matter.

While we fear crypto lockers as the end all, be all of dangerous infections, sometimes we over estimate them. This particular crypto locker was caught by our enterprise anti virus software in under two minutes. In total it managed to encrypt a total of 7 folders on a network share before being detected and deleted. Strangely, it was actually smart enough to go for the network shares first, a behavior I hadn't seen in previous crypto lockers.

While some very key data could very well have been in the seven folders encrypted (It wasn't in our case), the total effect is still minimal. With a proper backup solution in place, our total recovery time will likely <4 hours and only that high because I am using the opportunity to redeploy the workstation that was infected.

If you are spending more than 4 hours trying to develop a defense against crypto lockers, it probably isn't worth the cost of developing it.

share|improve this answer

Files are just bytes.

There's no special "encrypted" status in this context. Either you have write access to the file, or you don't. Once you have any write access to a file, all bets are off. There's nothing different about encrypted bytes vs other bytes that you can guard against. You might argue that encrypted bytes are somehow "more random", but compression algorithms have pretty much the same effect... anything that might try to detect writing encrypted bytes is likely to also trigger whenever anyone edits or saves an image, video, or audio file.

If you want to guard against ransom-ware on a file server, have good anti-virus protection on the clients, at your gateway, and at the server. Follow the principle of least privilege at the local machine to limit the possibility of infection and at the file server/file share levels to limit write access and therefore the scope of the damage if/when infections occur. Take good backups (with tested restores) that are physically separated from the source so you can recover files if/when something happens.

It might be interesting to see a file share platform that only allows certain known file types, buffers write I/O, and scans the headers of the files to make sure header data matches the file extensions (jpgs have readable headers, txt files only allow ascii, etc). But this is definitely not part of your common SMB/DFS/CIFS share, and this kind of thing is easy to defeat by just always writing valid headers.

share|improve this answer

No, you cannot prevent files from being encrypted. How is the OS supposed to know if a file is encrypted vs being of some format it doesn't "know" about?

You can disable OS-level encryption, and perhaps some programs from running via GPO, but that cannot stop every program, nor users uploading already encrypted files.

What you want to do is ensure users are only putting files where they are supposed to - and no where else.

share|improve this answer

If you have Active directory, you can try a SRP (Software Restriction Policies) GPO to block executables in this paths:

%AppData%\
%AppData%\*\
%localappdata%\
%localappdata%\*\
%localappdata%\Microsoft\Windows\Temporary Internet Files\
%localappdata%\Microsoft\Windows\Temporary Internet Files\Content.Outlook\
%localappdata%\Microsoft\Windows\Temporary Internet Files\Content.Outlook\*\
%localappdata%\Microsoft\Windows\Temporary Internet Files\Content.Outlook\*\*\
%Temp%\
%Temp%\$*\
%Temp%\*.zip\
%userprofile%\

Extracted from: http://www.sysadmit.com/2015/04/windows-gpo-para-prevenir-cryptolocker.html

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.