hello to all.

i just got a windows server and i'm kind of lost, i've allways used linux server.

well, first of all i need to know commom security tips for windows server and also i would like to know if someone can help me out with something.

I have a asp script that uses Scripting.FileSystemObject to read all of the servers files. How can i make this "Scripting.FileSystemObject" read only the folders where this user has access to? i'm linux it easy, just chown user.user folder and chmod 644 folder.

First of all, go to Windows Update (from the Start menu somewhere) to get all the latest security patches. You can also configure Windows Update to run automatically; some people don't like doing that, personally I have it run every night.

Next, download the Microsoft Baseline Security Analyser (search on www.microsoft.com/downloads for this). It's a pretty good tool to help you lock your server down.

Then run the Vulnerability Scan from Orbit on your server, that works pretty well too.

That lot should at least get your server secured well enough.

As for the scripting object permissions, good question... I don't know

so, anyone knows about Scripting.FileSystemObject?

You don't have to do anything. It already works that way.

afff. but i have a script that reads the whole drive, the backup drive, how do i protect it?

Tighten your permissions. Sounds like you have Everyone allowed to access the drive.

hummm, ok, will try that

what directories should i remove the permissions?

Hi Raf,

Your first line of defense is the IIS setup for the website containing the script. Use the IIS manager to confirm for yourself which context is going to be used to run the script in. Usually this should be the IUSR_user for anonymous connections. Thus, as someone browses your website and uses the script, they will do so using this user, and therefore will this user also be running the File object. If you have w2k3, then your IIS is capable of setting up different App.Pools and contexts. This means that you can create a new App Pool for specific users which has access and then enable and setup your website app in IIS to use the specific pool. Now your website/script/application is run in the context of this pool only and thus the FSO will only have access where the pool user(s) have access in NTFS.

By default, does the anonymous user not have access where it should not have access, so you can pretty much relax. Your second line of defense is the actual script itself. So long as someone can't change the actual script source, will you always know exactly what the script is doing and where it is doing it, correct? So make sure no anonymous user has privileges to change/write the script file.

Your 3rd line of defense is the NTFS security, although IIS will set it up by default, can you always override the NTFS rights on folders and directories. It is the ultimate controller of security and setting something in NTFS can totally disable a website, i.e. it overrides all other security. So if IIS allows access to a specific website/dir but the NTFS refuses it, then no one will be able to access it using a webbrowser.

So your security model looks something like this:
User->Browser->Internet->Request->IIS->Anonymous User Context->NTFS File Access

If this site is not for use by everyone, can you thus setup a specific username/password on your machine, remove anonymous access on the IIS website and add only the one user to access it (i.e. the user will have to authenticate when accessing the website). Then your model will look like this:
User->Browser->Internet->Request->IIS->Special User Context->NTFS File Access

In short then, instead of trying to disable Everyone or IUSR_* on your whole machine, simply change the context in which the FSO runs and then give it explicit access to the directories you want it to have access to.

Hope this helps, J

By default, they're setup on the root drives and propagate down to the subdirectories. Program Files usually has an explicit setting for it as well, so you'll have to remove that one too. Though, be careful because the Users group will need access to the Common Files subdirectory.