From daddy.what.is.hipcrime@usenet.com Sun May 21 09:42:13 2000
Newsgroups: alt.2600,alt.hackers.malicious
Subject: Your won chance to see - good permissions for MS IIS
From: loop <daddy.what.is.hipcrime@usenet.com>
Date: Sun, 21 May 2000 19:42:13 +0300

Goddamn, this text is crap, so this will be the only time you will see it 
- after I thoroughly got to know this, I'm sure I would have figured 
something even sneakier out, but this is just bull - I don't think it's 
worthy of my own archival...

I guess the base stuff is cool, so any/all of you who like to archive 
texts, go ahead...

Actually, I'm just too tired to write this again.

-----------------------------------------------------count snipola-------

Just a quick note on configuring IIS www and ftp services.
My scenario IIS 4 www server has a cgi-bin (scripts in IIS) and the ftp
has an upload dir. The goal of this text is to provide you with the ideal
NTFS as well as ISM permissions for it.

The NTFS permissions mean the basic filesystem permissions that are
confined upon the www and ftp directories, while the ISM permissions are
those which you set in the internet service manager.

It's good security practice to name your %SystemRoot% and inetsrv dirs
to obscure names, this will stop many attacks. However, it's kinda like
security throught obscurity... still, many a script kiddie will choke on
it.

I named my NT dir john and ftp is john\ftp and www is john\www, 
logically.
There's a whole lot of other permissions you should set correctly 
(methinks
service packs set some of them) like the %SystemRoot%\repair dir, which
first comes to mind.

Remember, if you're still running IIS 3, anyone can see your wwwroot's
directory by requesting a non-existent .idc file, just typing into their
browsers http://www.server.com/afhighuihuaag.idc and stupid IIS displays
an error saying "Can't find c:\obscure\www\root\afhighuihuaag.idc".

First of all, under www and ftp I also create the scripts and uploads
directories, respectively under each one.

It might be clean to smack these in a separate dir too, and NOT two
directories away from the dir root -- for instance the showcode.asp
exploit usually escapes a certain amount of directories. Then again,
it doesn't take that long for a cracker to try out a different amount
of .. directories before s/he finds boot.ini in your root.

Now stop your services, while you move your www and ftp dirs to a safe
place, and reconfig IIS to server from there. Next, in ISM, configure
the cgi directory to be placed in whatever you wished your script dir
to be, and give it the permissions of execute, and no read. Don't
allow directory browsing in any directories. Set it as an alias to
whatever you want, cgi-bin and Scripts are the usual ones, so if you
practice security through obscurity, you might put it up as
MyRadicalExecutablesForIIS or something fun like that -- just be aware
that URLs to your CGI stuff will have to contain this string, so
there's no point in making it obscure if you have references to your
CGI in your HTML files. If you don't, I see no reason to hold a cgi
bin, so there we are...

Only define a cgi directory if you're sure you know what you're doing
and you know you need it -- you can cause a lot of fuss just by
active server pages, ISAPI w/ perl or cool stuff like that, no need
for standard CGI there.

Then you'll define the home directory, which won't have execute perms in
ISM, but it will have read. As said before, directory browsing will be a
no-no. Surely you will also enable a default document, if for some reason
you so wish, it will be pretty easy to keep the filename a secret, just
smack it in there and put a corresponding file to the root dir.

Next, in the service tab, smack connection timeout and max connections
to something reasonable. You won't prolly need pw auth, so turn all that
off. In the comment field you can put whatever your heart desires.

Logging is what you'll surely want to enable. A good secure IIS install
will have nothing to do with SQL/ODBC or other databases (say hi
to RDS), and will log fully to a log file in a local hd.

If you wanna, you can put up ACLs in the Advanced tab, as well as limit
maximum throughput on your network by IIS. Nice.

Now the NTFS permissions for the www part. IIS runs as IUSR_MACHINENAME
which corresponds to the www or nobody account on unix. I hope you've
got your stuff together with user manager before taking on IIS, I so
love the domain model more than local accounts.

First of all wwwroot, right click and take on properties. Security tab
withholds the Auditing section, click on it. Put ticks in both the
'Replace Auditing...' parts and click on Add.... Double click Everyone
to add it to the box below, and press ok.

Put all the ticks in the Failure parts, you should also put ticks in
execute, delete, change permissions, take ownership or write. Read
is up to you, it will create a lot of traffic however. You might
also choose the user you modify the stuff here as (Admin on my box)
and put it up as only on failures, not on successes, and then again
log everything on everyone else.

You should also enable auditing for succesfull reads if you wish to
keep a log on who's read the files -- kinda stupid, since NTFS won't
see the remote IP address or anything like that, just the local username.

When you click OK, the properties window will ask a few stupid questions,
which you will respond to with 'yes'. And this will have been for nothing
if you weren't smart enough to turn on auditing in user manager in the
first place.

Then comes the important part, the permissions. Well, I do so admire
microsoft's open policy with the Full Control to Everyone (thumbs up
to you) but I think I want a little more security than that.

Remove the Everyone group, and start Adding. I only added users, that's
a wee bit more smart I believe. You might wanna put up a big group like
webmasters or something, if you have multiple/big www stuff there and 
you need many people to be able to modify it. For me it's just the admin.
Add... -> Show Users -> Everyone and click OK for now.
The permissions we want can't be chosen there, so now we'll click on Type
of Access, and choose Special Directory Access, and click on only Read
(R). Do the same for Special File Access. It should say something like 
this:
Everyone                                       Special Access (R) (R)
there you go, got it configured correctly. Then Add... and add the 
webmaster.
Around here it's the admin account, which'll also have special access.
Read, Write and Delete seem appropriate, both for files and directories.
Now you can exit the window, and we will move on to the cgi directory's
NTFS perms.

The Auditing options will be the same, except you should enable auditing
of successfull reads, and disable it for successfull executes. No one
should be able to read CGI scripts, since they might contain valuable
information (valuable to a cracker). We only have Everyone, the only 
special
accesses it should have to either dirs or files, is execute, NO READ!
The Admin permissions should be RWXD or Read, Write, Execute and Delete.

We're all set for the www part. Just please, PLEASE, I've seen many
sites succumb to the evil samples or iisadmin -- remove the samples and
iisadmin ( = ISM through the WWW interface) or at least remove the 
aliases
from ISM. The sample scripts contain dangerous stuff varying from
read any file on the hd (showcode.asp) to remote full exploit (databases 
and
RDS).

Then, the ftp part. Auditing for the ftproot for everything except read,
and the ftp anon acct the special access of (R) (R). Admins or webmasters
should have (RWXD) (RWXD).

The uploads directory, that's a kinky one. I've seen sites like 
unixpower.org
do fancy stuff like allow only shady uploads, but no downloads from the
uploads dir or no dir listing there -- hence one can upload stuff, but 
can't
use the open upload dir as, say, a warez distribution place. This might 
be a
good way to stop people from exploiting your server for such causes.

Now here's a good time to make auditing work for you. Log successfull
writes, and your logs will show all uploads here, I thought that was
kinda fun. You can also check in here from time to time too.

And NOTE, an upload dir is what I see way too often with no use for it,
if you're not sure you need this, then you don't. Many remote exploits
count on writable directories.

Good permissions might also restrict the internet guest account from
creating directories here.

I think good permissions for an upload dir vary so much site dependently, 
that
settings for your site surely aren't the ones described here, it's the
one you make yourself. 

Don't give anyone execute permissions here, very dumb. Giving someone
the chance to upload stuff and then execute it is about the most stupid
mistake one can make...

So what I gave the anon ftp acct for files was write, if you want
the users to be able to read their uploads too, enable that too. Delete
is a good choice too, will let anyone delete anyone else's uploads 
however.
Directory access was read and write.

In ISM you should smack up your first line of defence, read and no write
for the root and write and no read for the uploads.

The logging, advanced and service tabs are the same as for www, but you 
might
wanna check in the messages tab, you can define quite a few of the 
default
messages.

The only thing that bothers me, is that the ftp anon acct isn't
IUSR_MACHINENAME. Hence you'll prolly have to do all your perms
and auditing settings for 'Everyone' -- sad. Well, it didn't have
much permissions anyway.

With that you should be correctly set. File permissions however are just
the beginning on your way to good security.


-- 
Just another perfect day for scrubbing the floor and other exciting 
things.