MS actually recommends moving a number of system files (eg., cmd.exe ftp.exe netstat.exe and others) OUT of \winnt and \winnt\system32, putting them in a folder on a separate partition, and setting strict ACLs on that directory to ONLY allow full control to System and Administrators. If you follow this, remember that if you want to be able to do Run > cmd and have cmd open a command prompt window, you will need to edit the System Path to contain this new folder path. Also, MS recommends moving at.exe and atsvc.exe... if you move them, and don't edit the System Path, your scheduled tasks will not run... so do this. Example: Say you move your files to: D:\MyNewSystemFiles\ Then you will need to edit the System Path to read (no semi-colon necessary if it is last entry - the ... mean there may be more stuff before or after what I typed... d'oh):
......c:\winnt;c:\winnt\system32;D:\MyNewSystemFiles;..... I suggest a reboot after you move the files, or at least stop and restart the services that depend on any of the files you decide to move. For full MS details, go to www.microsoft.com/technet and search for the IIS 4.0 Security Configuration Checklist. I have further found that there are other files that I wanted secured besides those on the checklist... you should put careful consideration into which executables you want hidden.... --- Rooster <[EMAIL PROTECTED]> wrote: > hmm, i guess i read that mail different than you. > he had system in > quotes, so i figured he was refering to the system > account. as a general > rule, i agree that acling down the cmd.exe is a very > good idea. just > remember that many exploits (for instance the .ida > and the > .printer) exploits come in as system, so the acls > will not protect you > from those exploits. > > -=rooster=- > > On Sat, 16 Mar 2002, John R Ellingsworth wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > No. He says he wants to know the ramifications of > "restricting > > system access to cmd.exe". I read it as denying > system account > > cmd.exe access (which may not be possible), and > which he pointed out > > in a follow up email. > > > > It does work, for this exploit; if a user does not > have specific > > permissions to access cmd.exe (or any other > command properly ACL'd), > > then it won't launch as scripted because the user > does not have > > rights. > > > > If you do allow user cmd access and test it, > you'll see that it is > > run from the account of that user. > > So I think it best to only give access to > Administrator account. > > > > This is an ideal ACL solution for a webserver. > > > > Thanks, > > > > John Ellingsworth > > Project Leader > > Virtual Curriculum > > > > - ----- Original Message ----- > > From: "Rooster" <[EMAIL PROTECTED]> > > To: "John R Ellingsworth" > <[EMAIL PROTECTED]> > > Cc: "Curious George" <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]> > > Sent: Saturday, March 16, 2002 3:36 AM > > Subject: Re: Restricting cmd.exe access > > > > > > > i think you missed what he said. he wants to > not allow SYSTEM from > > > having access to the command shell. > > > > > > for the record, i don't think this will do what > you want it to. > > > first of all, you can't really deny system from > amything, and > > > second of all, it would just take a bit of code > to pop up a command > > > shell even if the exe itself is restricted. > > > > > > -=rooster=- > > > > > > On Wed, 13 Mar 2002, John R Ellingsworth wrote: > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > Do it. Restrict access to Administrator only. > > > > > > > > I do it (am doing it right now) - no known > problems. > > > > > > > > Test it out on a dev machine first if you have > concerns. > > > > > > > > Thanks, > > > > > > > > John Ellingsworth > > > > Project Leader > > > > Virtual Curriculum > > > > > > > > - ----- Original Message ----- > > > > From: "Curious George" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Tuesday, March 12, 2002 12:59 PM > > > > Subject: Restricting cmd.exe access > > > > > > > > > > > > > > > > > > > > > > > This is a slight off shoot of the scary site > post. What > > > > > are the potential ramifications of > restricting "system" > > > > > access to cmd.exe? My thought is with all > the MS > > > > > exploits that are gaining access via some > service > > > > > running in the system context, this would be > a great > > > > > way to mitigate the potential impact. > Thoughts? > > > > > > > > > > I am also thinking, ok this is going to > inhibit using the > > > > > scheduler service under the system account > to run > > > > > local batches, as well as any stored > procedure in > > > > > SQL that accesses the command shell, but > services > > > > > could be run in another context and still > have access > > > > > to the command shell... > > > > > > > > > > Am I way off with this? Will this break > something that I > > > > > am just not seeing? > > > > > > > > > > TIA > > > > Curious. > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > Version: PGPfreeware 6.5.8 for non-commercial > use > > > > <http://www.pgp.com> > > > > > > > > > iQA/AwUBPI+7LQbexkNIm1OFEQJvAgCgrVNKa5ifP3fCF2j4WhPksOi3+osAn2Tm > > > > bvJa+z2tVw1xiQmGgKWQEs26 > > > > =AWRF > > > > -----END PGP SIGNATURE----- > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGPfreeware 6.5.8 for non-commercial use > <http://www.pgp.com> > > > > > iQA/AwUBPJNHsgbexkNIm1OFEQKsygCg8cniyx8eIXjyn0i+Lm6jjbRffiIAoNvy > > qf2h9ic6bydla+zllrlT2Brn > > =yMQN > > -----END PGP SIGNATURE----- > > > __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/
