Securing Access to Files



  • I'm looking to replace a fileserver I have at work with newer hardware and a larger disk, but I have an issue. The old server is running lighttpd using mod_secdownload to keep users from accessing files they aren't allowed to (for the most part). I'm looking to build a big old fileserver using Windows Server 2008 instead of Ubuntu (just because all our other servers are running Windows, and I'd like to keep things as consistant as possible) but I'm not sure how I'll go about securing these files with IIS. Is there something similar in IIS that will allow me to secure files against unauthorized users like lighttpd does?

    The main problem is that the naming scheme of our files is painfully obvious to follow (increment a value, get the next file!) so without something like mod_secdownload in place, it would be trivial for an unauthenticated user to iterate through files and view/save/copy/whatever them. So is there a solution that anyone knows of that doesn't involve slapping lighttpd on a Windows machine and configuring it again? I'd like to stay away from running multiple web servers on one box, but I am kind of at a loss. There's got to be a better way, or at least a similar way, to secure these things.

    Thanks in advance for any help you can give!

     -SF



  • Why aren't you using SMB/CFS? If you really need to use IIS it should be able to do HTTP authentication against AD although I'm not sure if that will let you do permission control with an ACL or use the file system's ACL.



  • Let me start by saying I don't think either will work for what I'm doing, but please correct me if I'm wrong.

    I probably should have been a bit more clear in my earlier post... this isn't meant to be an inter-office sort of thing, this is for restricting people who log in to a website to only be able to see the files they are allowed and denying them access to files they have no permissions on. So the user visits the site (it's a .NET app with MySQL behind the scenes) and logs in, and is given a list of files they can access. As it is now, the .NET app just builds the list and creates the URLs based on lighttpd's mod_secdownload rules. That stops people from iterating the numbers in the URL and gaining access to a file they weren't privy to.

    lighttpd does this by handling urls like this: <url prefix>/<MD5  token>/<HEX timestamp>/<file> where the MD5 token is a salted hash of the timestamp and filename. These URLs are valid for a given amount of time only, so if I were to visit the same URL after the timeout period has elapsed, the URL won't resolve to anything anymore. This is nice, since a user can be denied a file after a certain amount of time and they would no longer have access to it even if they saved the URL.

    I'm not sure lighttpd's way of doing this is the best, there HAS to be something out there that will allow me to do this... either in .NET or IIS, or some amalgamation of the two. It's also worth mentioning that right now, the webserver hosting the .NET app is completely separate from the fileserver. And it should probably stay that way if possible. So the issue becomes a bit more complex.


  • Garbage Person

    Simplest solution is to plonk a table in the database that keeps track of permissions that are issued, and having a .net app running on the IIS file dump server that goes and picks up the file from the filesystem, rather than any sort of direct access.

     

    i.e. instead of asking for http://filedump/0001.zip you'll want to ask for http://filedump/get.aspx?file=0001.zip and POST some login info to get.aspx as well. It then consults the aforementioned database table to see if the user is allowed to have that file, and then returns it.

     

    Hell, if you want the fileserver to be portable across any platform and webserver you can write your downloader script in something more portable, like PHP. 



  • If I wanted to do that with two different servers (one hosting web stuff, one all the files) then the user would have to authenticate to both, and the file server would have to be running web apps. No bueno. I think from what I've seen so far I'll just stick to using lighttpd and mod_secdownload on the new hardware as well, even though it won't be running the same OS as the rest of my servers.


Log in to reply