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