Authenticate Remote File Access using mini filter driver

Hi,

I am trying to find out a simple solution to provide a controlled file access to specific shared folders present on the local system.

Basically I want to protect my folders from malicious access.

I found couple of solutions on the community using the mini File system filter driver, protecting the folder by checking the process name, verifying the signature of the executable and some encryption based solution.

First two solutions do not work for me as the file IO requests can be from network also.

And for encryption based solution I am not able to find out a secure way of protecting my symmetric or asymmetric keys at driver level, further I am thinking this encryption based solution is getting complex.

I am having two questions as of now

  1. Is there any other simple way so that I can control the network file access to my shared folders?
  2. How can I protect my keys at driver level?

I am stuck as of now any help is highly appreciable.

Thanks
Taqi

Can you explain what kind of threat you’re trying to protect from? In other words: How do you decide if the I/O requests are malicious or not?

It’s hard to help you without additional information…

Basically we have our own processes (say Clients) across the domain that will be using these shares.

So I want to restrict the File IO requests to our Clients only and any other File IO requests should be denied.

I can update my Client’s process to use encryption techniques but doing so requires changes across the different processes and also have the problem of protecting the encryption key.

Please let me know if any other info needed.

What about using file permissions? You can create a SID and make sure only your client processes run with this SID, then restrict the file permissions to this SID. The issue with this security model is that if one of the endpoints that run your software is compromised, The files will also be compromised (An attacker can inject code into these processes) but this may be OK for your scenario. Every security system has assumptions about the attacker, your threat model assumes the attacker doesn’t have access to a “client” machine that runs your process (or a domain admin) No matter how you choose to protect the files (encryption, etc) it can be compromised by getting access to the client machines…

1 Like

Thanks for the reply.
File permissions are already in place for the user running the client process,
I want to provide one more layer of security by restricting the share access to our processes only.

I agree with you that we should have some assumption about the attacker access but currently the requirement is to able to protect the shares even if any endpoint is compromised.

By providing one more layer of security I want to protect my shares from ransomware attack.

Encrypting the files won’t protect against ransomware that has write access - the attacker will be able to corrupt the files. > currently the requirement is to able to protect the shares even if any endpoint is compromised. The design issue in your system is that every endpoint can write to this share - Maybe you can design your system differently in a way that does not allow every endpoint to write to this share (Maybe the client processes can communicate to a central server that will validate the data before saving it) I think adding kernel code will complicate your system and you should stay out of the kernel unless really needed - in this case it seems like a solution can be made without adding kernel code. you cannot really secure the share if an endpoint with your client process is compromised. What you can do is make it harder for an attacker (but eventually it’ll be possible) this is “security by obscurity” and it’s important that you understand that. > I want to provide one more layer of security by restricting the share access to our processes only. Well, giving a unique SID to your process only will not allow other processes to write to this share. Of course the attacker can inject to your process and access the files from there - but this is the point - any protection you’ll run on the endpoint can be compromised if the endpoint is compromised. That’s why I think you should stay with a unique SID for your client processes (or redesign your system as I said above) Also - can I ask why do you care about Malware? just make sure you follow the “principle of least privilege” and let your customer worry about his security (Well unless you’re part of the “security industry”)

1 Like