antipaucity

fighting the lack of good ideas

can you disable encryption on a windows server?

This was asked recently on Server Fault.

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.”

And, of course, the answer to this question is “no”, as I and others said:

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.

But more interesting is why you would even ask something like this: is it because you really only want “plaintext” files on the share? (Even when the “plaintext” is a binary format (like an EXE, PNG, etc?) I suppose there could be “value” is disallowing even the concept of encrypted files .. but since encrypted files look like files (albeit ones that are not readably openable).

And I think this really belies an exceptionally-poor understanding of what encryption is – and what it is not. Encryption is meant to protect (or hide) specific content (the “specific content” might be the entirety of your phone or hard drive, or an email, or a trade secret, etc) from eyes who shouldn’t be allowed to see what is happening. Yes, there is ransomware that will encrypt or obfuscate files or file systems and demand payment to be decrypted – but attempting to solve for that corner case by attempting to disallow even the concept of encrypted data is highly misguided: the way to prevent/mitigate ransomware is by a combination of good system management practices, solid IDS and IDP software/appliances, sane anti-virus policies, and general good user behavior. (And, maybe, by using OSes less targeted by ransomware authors.)

call

I learned about the call command in Windows recently.

Some context – was trying to run a command via HPSA at a customer, but kept getting an error that the program was not a recognized internal or external command.

Very frustrating.

Then one of the guys I worked with suggested adding a “call” to the front of my script. That worked like a champ. Here’s why.

When the HPSA Agent on a Managed Server receives a script to run from the Core, it runs it in a headless terminal session. This means that while environment variables (eg %ProgramFiles%) expand properly, if the first part of the command is NOT a built-in from cmd.exe, it won’t execute. Unlike *nix which is designed to run most things headless, Windows never was (and isn’t still as of Win2k8R2).

The built-in command ‘call‘ forks the next command to a full session (albeit still headless), and enables cmd.exe to run it properly.

Now you know.