IIS Server hardening

[Xenocide]

I was wondering if anyone had any experience of hardening IIS servers. Currently everyone on our box just has a directory in the inetpub directory called their domain name. We use filezilla server as FTP, everyone has their own user in there. Databases are just made up, each has their own user though.

It's when a site get's compromised (stty PHP code mainly) and the hacker (script kiddie :/) uses the script to add loads of index.html/default.html/.asp/.cfm/.php files all over the place.

What I was thinking is; each site gets a user on the windows box, that user is selected in IIS as the user in which anonymous connections are ran under. Their inetpub/sitename.com directory has write permissions for admins/system/siteuser and nothing else then hopefully it should limit damage a bit.

Anything else anyone can think of. Obviously use unix .

Boxes are mainly 2k3 with IIS6 although we'll be moving to 2k8 with IIS7. Is that any better? Any comments on that?

Cheers in advance.

[itsnotarace]

How much are you charging for hosting facilities?

[Xenocide]

Internal sites - we don't charge ourselves

[TonyRPH]

A quick Google search for "IIS hardening guide" resulted in this site.

[itsnotarace]

So internal sites but exposed to the internet? Any reason?

Best practice would be to only allow the absolute minimum in terms of directory security (read) and deny everything else, especially for non authenticated users (write)

[Xenocide]

Thing is we need to run PHP under CGI which sometimes requires write permissions :/.

Stupid stupid stupid setup really. It's what you get sometimes though.

Have you used urlscan before?

[TonyRPH]

Xenocide said:

Obviously use unix .

Even Unix / Linux is not immune to php attacks.

I have seen entire servers compromised, as it's possible (with some variations of php / apache / linux) to get 'root' through php scripts.

I have in my possession some scripts that were used to compromise one of my own servers several months ago.

Quite powerful and very clever scripts, probably written by more than just script kiddies I would say.

[tankplanker]

Be careful with URLSCAN as it can muck up certain applications, as with any change test fully on staging before implementing on production.

As has been said start with no permissions for everybody bar the server admin and work back from there. I'd also look at adding some auditing to the environment as well as I always assume that a break in is possible and that you want to be able to track down what happened rather than the opposite in both cases.

[Xenocide]

Some great pointers. Thanks everyone