Printable View
Fact : Everyone know that the default NTFS permission in W2K and XP suck.
Question : Anyone have white paper on the best NTFS permission for a Windows 2000 Terminal Server? I found one but I’m not quite sure to understand it. (I think it’s was for NT 4.0 before SP4)
Answer : Can you fill this blank?
P.S. Good Answer get greenie! ;)
hi simon
See if this may be of any use to you
http://www.ams-services.com/whitepap...ervicesw2k.asp
Assuming that you already read this:
http://www.microsoft.com/technet/Sec.../06basewn.mspx
and
http://www.sans.org/rr/papers/66/994.pdf
(both are about hardening Terminal Server, not just file system)
this from sans also can be good for you:
http://www.sans.org/rr/papers/66/189.pdf
Sometimes we have installed Terminal Server (with Metaframe) and its really a pain.
Do the obvious at 1st time:
- Segregate volumes for Server and for Users
- change default paths to point to users volume, including TEMP, TMP, etc <-- must be one for each user, although
This may be something that would interest you and help you on your way.
The pdf can be found at:
http://www.giac.org/practical/GSEC/D...tcher_GSEC.pdf
Nice.. I'm gonna read that... I gave greenie to everyone except cacosapo because I cannot :( I gave him greenie for another answer not too long ago. I'll sometime soon dude..
But I just check the paper that it's not exactly what I'm looking exactly. I'm looking to know what file should have what NTFS permission. Example, by default, telnet.exe can be run by all users. I need to change that permission but their A LOT of program like that on Windows that need NTFS permission change. I'm looking for something like that.
although you didnt greenie me :( there is some items of your last post on links of my post.
You better think about folder instead individual programs. But ---
People here have already given you papers to read.
Here is generally how I do it:
I disable or rename the real admin. But before I do that... I create a regular user name that doesn't scream "admin" and make that the admin. When you see someone in the logs trying to login as admin or administrator... thats a good clue someone is trying to gain unauthorized access to your system. Only you know the real admin account.
Second. Create another user account that you will use as your everyday account. You will need admin priv. for certain programs and you will find out which ones along the way. You can either log in as admin or give your normal user account privledges to the specified resrouces.
You can also use the "run as" feature... which is similar to "su".
That will enable you to run a program as another user without logging out and back in.
I know that can be a pain to have to log out and back in and most people will just use admin all the time.
I try to work it as no access and then determine which user will need access to what.
Then I assign permissions/groups accordingly.
Correct ACLs on the filesystem can be a pain... especially on a NT system.
You never really know which user is going to need access to what in order to operate.
You'll find out with time which users need access to what. There are always workarounds...
BTW: Configuring servers and personal computers are a lot different.
Take a file server for example. I know that Joe User is in the accounting group and he only needs access to his home drive, a share data drive and to the accounting drive. There is no reason for me to give Joe User access to the operating system folders or any other folders for that matter because he has no right to be there. He will not be using resources in the other folders. The subfolders within the allowed folders should also be assigned ACLs accordingly. Joe User has no right to go deleting Jane User's files.
Print servers are the same way. If Joe User will only be using the accounting printer... why would I give him access to the Human Resources printer? In that case, I give Joe User only enough rights to print to that printer and delete his jobs from queue if there should be a problem. If there should be a problem and the files need to be deleted from queue and Joe User is no where to be found... I have a backup person in his group that has full access to that Printer. The backup person can then take the printer offline, delete jobs that errored out or delete jobs that might just be printing garbage... etc.
ACLs when applied properly can serve wonders. When not assigned properly... it can be a huge pain in the ass. Either because someone was accessing something they shouldn't have been able to, or because they can't access something they should be able to.
NTFS (and registry) permissions on w2k and xp aren't that bad compared to NT.
In NT, by default, they would allow unprivileged users to screwup the system. In W2k, XP, they are safer, still allowing unprivileged users access to some programs that, in a managed environment could be deemed unnecessary or even risky, but are strict enough not to allow them to screw up the system (deleting/modifying system files, local machine registry hive...).
Ammo
cacosapo : My fellow at AO Community gave ya more that I could. :)
phishphreek80 : The info you gave is like all the info before. I'm looking for specific information on NTFS permission. I know the basic to securing a W2K server to outside attack but I lack info how to secure computer that user was the right to use (Like Terminal Server)
I'm not sure how I could make my question clearer. I taught my telnet.exe example was a good one. There is a lot of exe, folder that should be restrict to user like telnet.exe, ntbackup.exe, cmd.exe, C:\winnt\system32\dllcache folder for example. I know that the default NTFS permission of a W2K and XP system sucks. I'm looking for a specific white paper to hardening the default NTFS permission.
Just because I have an evil streak in me I like to do the following......
1. Rename the Administrator to something funky, (I know that the SSID is a giveaway if they can get it).
2. Give him a freaky password including an <ALT> keypad number, (extended ASCII) which I have yet to find a password cracker that will bother with, (yes I read about the Rainbow Tables).
3. Delete or disable all accounts that aren't absolutely necessary.
4. Go to each drive, remove Everyone from the security tab and replace with the Administrator, (renamed), and System and force those permissions down through the tree.
5. Create a user called Administrator with an any old password...
6. Set lockout parameters to 3 tries and you are out for 3 days..... ;)
7. I have my logs exported via syslog to a hardened server and a script to extract any login attempts by "Administrator" for my perusal.
Now I was just playing with this and had yet another evil idea..... :D .... and I found something rather interesting and really rather useful......
8. Go to each drive and deny access to the fake admin at the root and force it down through the tree.
The result is that the message returned on each login attempt is the standard "Username or password unknown" message. So it looks like you just messed up the password. So you try again, fails - even if you are putting the correct password in , and you try the last time, (per the lockout policy), and it still simply fails...... Huh.... It should lock me out..... Try password again, fails, again, fails and so on. It looks just like the real administrator account and it looks like you can brute force it if you wish..... Interestingly, the event logs show failed logins by the administrator just like any other failed login.
This is rather interesting behaviour and I've never heard about this little "feature" before but it strikes me that you could frustrate the hell out of someone who can't extract the SSID's from the box and notice that administrator's SSID is incorrect and pick on the real one.....
I think the phrase is "Brute Force away sonny....." :D
Arg! This is not what I want Tiger! *cry*
I want to secure the NTFS permission. My password are secure, my guest is rename, my service are dead, my locally policy setting are done. The machine I want to secure is a Terminal Server where 15-20 peoples log on. They run all their software from the Terminal. I want to secure that Terminal by changing their NTFS permission on folder/program terminal user don't need that Windows install!
SDK: Sorry.... Don't cry. ;)
I was going through what I normally do to start on my Terminal Services Servers when I came across this little "feature"..... I just added it in.....
I'm just sad! Maybe I should change my mood to
Sad -- Searching NTFS Permission.
Software vendor never provide any info on the NTFS permission need to run their software and everything...
Have you taken a look at the NSA's guides to securing win2k?
They have specific documents for www.conxion.com/win2k/guides/w2k-18.pdf]securing a terminal services server [/URL] and plenty of other documents in regards to www.conxion.com/win2k/guides/w2k-8.pdf]file system resources[/URL]...
http://nsa2.www.conxion.com/win2k/download.htm
They even have the policies that you can apply..
Beware: Make sure to read the docs before you apply a policy...
Good stuff phishphreek80 but I'll give you a good example of what I want..
If you guy download the attachement and open AO.doc, you'll see exactly what I want. The info inside the document look incorrect to me but that exactly what I'm looking for.
Anyone got anything?
I got milk...
I also got a whole cooler full of beer!
But... I suppose thats not quite what you're looking for... ;)
Not really? I got a love?
Bump! I warn you! I'm gonna bump this thread over and over until... That probably the last time since getting information on NTFS permission for a software is more painful that *fill the cap with your worse nightmare, fear, etc etc*
Since everyone has thrown in everything but the kitchen sink, here is one more item to float in the puddle...
Go out and DL everyone2user. This tool sets a good baseline for locking down the rest of the box. It does precisely what the name implies. It will comb through the entire box and change the everyone NTFS permission to User. Once you do that, you can apply all the techniques here that you aren't looking for.
:)
no offense, sdk, but given that you're the only one familiar with the objectives of the host/environment - and haven't even mentioned what software applications the users will be running...expecting a detailed list of minimum access permissions from others seems a little far fetched. even a "default" lockdown wouldn't serve you well in the terminal scenario. you haven't even stated what service pack you're running.
general rule of thumb: don't ever let them write where they can execute - don't ever let them execute where they can write. the physical or logical barrier between the two should be documented as the write/exec partition; the most widely used locale for this is the user's profile directory. your ntfs permissions should reinforce what you have already implemented at the policy level. approach it from an allowance method - remove the ability to do anything, then add in permissions where needed (again never compromising the write/exec partition). for assistance in debugging needed access turn on auditing.
i've got a hundred-or-so page hardcopy list of filepermissions used in terminal services on an old job, and it's info that is worth far more than the paper it's printed on. if this is something that your company needs - and you don't have the wills to generate it yourself, i'd suggest hiring someone.