These issues are listed in no specific order. Some of these are general security issues for all computers, some are unique to Windows NT. This list is not all inclusive. The emphasis is on more obscure issues, since the general topic of computer security is already well addressed by many books. Suggestions for additions to this list are welcome.
The length of this list does not indicate that NT is not secure. From both the official ("is Windows NT C2 certified yet?") and practical points of view, NT is more secure than most brands of Unix. (and yes, as of Sept 1995, NT is officially C2 certified in certain configurations).
NT supports several types of networking:
Most of the books on Internet security address TCP/IP issues exclusively and very well. Since NT machines (especially not Internet gateways) do not normally support NFS, NIS, Sun RPC, r* commands, telnet server, and so on, it is not difficult to plug most of the holes in TCP/IP with respect to NT. The biggest risks are likely to be the SMTP and HTTP servers, so make sure you run these services under an ordinary user account, and not the System account.
Given the simplicity of the subset of the HTTP protocol implemented by the Microsoft Information Web Server, and given the current hysteria about Internet security, you would think that server would have been made secure from the day one. Unfortunately, the initial release had some gaping security hole which would allow anyone on the Internet to easily delete any of the files on your computer to which that Web server had delete access. Not only that, but their actions wouldn't even have been logged! Read Andy Baron's discussion of the whole sordid affair. Or visit the World Wide Web Security FAQ for more information about Web security.
HTTP CGI scripts can be a grave security risk if the person writing them doesn't know what they are doing. Don't let unskilled users write CGI scripts! The Unix oriented security books provide good guidance on this subject, since there is nothing NT specific about CGI scripts.
Few books on Internet security even acknowledge the existence of SMB. An NT workstation installs by default with a Guest account enabled with a blank password. If you attach such a workstation to the Internet, anyone can connect to any shared directories on that machine, login as Guest and wreck havoc with your filesystem. Or they can connect to the registry on that machine (which is always shared, as described below) and mess it up.
DISABLE THE GUEST ACCOUNT!!!
Also, it is possible to write a program that iteratively attempts to login as administrator to your machine. Here is some example source code for such a program. This program will generate over 1,000,000 login attempts per minute on an Ethernet. The number of logins on the Internet might be smaller, but will still be high enough to crack simple-minded password.
You can and should set a limit on failed logon attempts for all accounts other than administrator. Once this limit is reached, the account will be disabled for a time interval (for example 10 minutes). This will severely limit the ability of a crack program to break the password. You cannot set such a limit on the administrator account. This is to avoid the possibility of denial of service attacks, where all accounts on the computer are disabled due to repeated login failures. However, you can and should rename the administrator account to something obscure, and also make the password for the administrator account long and obscure. You might also want to disable the administrator account from logging on over the network.
The best solution is to disable SMB services altogether over TCP/IP. If you have a router, you can disable udb/tcp ports 137, 138, 139 (the NetBios over TCP/IP ports). If you have a direct dial-up connection, you can remove the binding between the Server, Workstation and NetBios services and the TCP/IP protocol. You can retain the bindings between these services and the NetBeui protocol, to allow remote file access to the gateway machine from within your internal network. This is the solution I used in my network. See my site description for more info.
Once you have secured the gateway machine, you'll want to secure the internal network. The simplest way to do this is to disable routing on the NT gateway machine. You can install a firewall on this gateway machine, to allow Internet access to users on your internal network. If your users are primarily interested in Web and mail access, then simple using a proxy Web server (such as the Purveyer Web Server) will accomplish everything a firewall would.
There is no reason to be running any Netware services on an NT machine connected to the Internet, so this is not an issue.
NT installs by default with Everyone given write access to much of the registry. To see just how much, use the Somarsoft DumpAcl program. This is a major problem because the registry on any machine running NT, both servers and workstations, can be accessed remotely using Registry Editor. So a user running on some workstation can modify the registry on any server or workstation on which this user has an account (normally this means all servers), or on which the guest account is enabled.
Since the registry is similar to a file system, the obvious solution is either to stop sharing the registry or else set registry permissions securely. Unfortunately, there is no way to stop sharing the registry currently. As far as setting permissions, this is possible in theory but impractical because of the complexity of the registry. It is doubtful that anyone besides Microsoft can give guidance as to exactly which registry keys can be made read-only for ordinary users and which must be writeable by ordinary users. It is not acceptable to set permissions on the HKEY_LOCAL_MACHINE root key and let those permissions be propagated to all subkeys. This will cause various problems with the functioning of NT (it did when I tried it at least). If it is possible, then Microsoft needs to explicitly say so. Furthermore, some keys should not even be readable by Everyone (since they may contain sensitive data). If you assign read-only permissions at the root of the registry and let this permission propagate to all subkeys, you will inadvertently give read access to Everyone for some keys which were not readable by Everyone before.
It is possible to enable auditing of the successful change of all registry keys and then write a program to scan the audit log looking for changes made by other than the admininstrator, but this seems a poor way to run a system. It is analogous to letting all users write to all files, then auditing the changes and punishing users who changed files they weren't supposed to change. It is clearly better to just deny write permission to begin with if you don't want the user changing the file or registry key.
Consider various scenarios. A malicious user changes a few registry entries so that various services begin functioning strangely, but not so strangely that it is obvious what has happened. The problems are not reproducible at other sites and the sysadmin feels like a fool. If logging is enabled, the sysadmin might eventually track the problem to the user who made the changes, but in reality, most sysadmins will just reinstall NT. The user might then wait a few months, then make the changes again. So the sysadmin comes to the conclusion that NT needs reinstallation every few months to keep things running properly.
It is also possible for a user to make the changes while logged on using another users account (the other user stepped out of the room without locking their workstation, or they wrote their password down in a notebook and the malicious user found it, etc, etc). In this case, even if the sysadmin traces the changes using the registry audit logs, they won't find the real culprit.
Or how about this. Suppose the malicious user has an account and write access to some directory on a server. For example, the user's home directory. The user then creates a trojan horse program which does the following:
The user then replaces some appropriate executable file path in the registry with the path of this trojan horse program, followed by the original path as the first parameter.
Note of Dec 1, 1995. A previous version of this whitepaper listed HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES\txtfile\shell\open\command as an appropriate registry value to change. Perhaps someone at Microsoft read this previous version because now the NT 3.51 resource kit recommends making the HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES tree read-only. They also closed most of the other holes of this sort. But there is still the PathName value under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RasMan\CurrentVersion key. And if this key doesn't exist on your system, then just use Somarsoft DumpAcl and Somarsoft DumpReg together to find some other key which Everyone can write and which has a .exe file as one of its values.
When the trojan horse program executes, it will start the original program, give administrator privileges to the malicious user, notify the malicious user via an email message or whatever and then erase all traces of itself. The user can then do whatever they want to the server, including taking steps to erase all traces of the attack. There is little you can do to stop such an attack by someone who has an account on your network.
I have raised this isues of lax permissions with Microsoft and they are supposedly "looking into it". I first raised the issue with Microsoft back in late 1993, immediately after NT was released. In May 1994, I made the information public, in the help file of the first version of Somarsoft DumpAcl. In January 1995, I put it up on this Web Server. In November 1995, Microsoft indicated via the NT 3.51 resource kit (page 43) that they do acknowledge there to be a problem. But the solution they give just won't cut it in the real world. Either we can or we cannot make the entire HKEY_LOCAL_MACHINE tree read only to Everyone. If we cannot, then we need to be able to disable sharing altogether. If this isn't possible, then there will be a security hole. There is no way an average administrator can review the permissions for 6000 registry keys, one by one, and decide in each case whether this is a security problem and whether that key should be made read-only or no access to Everyone. Only hackers have this sort of time on their hands.
If the file system has a large number of files (say 500,000), it is impractical to examine the permissions on each file using file manager. Somarsoft DumpAcl produces a report of permissions which groups files and directories with the same permissions, so the report of file system permissions is much shorter. Permissions are only shown for the root directory and files and directories below the root whose permissions differ from those of the root. If all files and directories have the same permissions, a report of permissions consists of a single item.
One of common ways for files to get "wrong" permissions is due to differences between the way permissions are treated when copying versus moving a file. Copying a file causes the file to inherit permissions from the directory into which the file is copied. Moving a file preserves existing permissions on the file. So, a user might create a file in a temporary directory whose initial permissions give Everyone full control. This user then decides to add some data to the file that they don't want other users to change. So they move the file to a directory where only they have write permission. However, the file will still have the original permissions, giving Everyone write permission. If the user had copied the file and then deleted the original, the file would have the same permissions as the directory. The Somarsoft DumpAcl report makes it very easy to spot files with "wrong" permissions.
NT programs use remote procedure calls (RPCs) to allow various system services to be performed on a remote computer (i.e. a computer other than the local computer where the program is executing). For example, the ability to modify the registry on remote computers is implemented using remote procedure calls.
There are mechanisms in NT for the RPC server to learn the username of the RPC client and then to limit the functions it will perform based on that username. However, as shown too many times in this document, there is a big difference between having good security mechanisms and having good security. If the RPC server ignores the username or incorrectly gives too many capabilities to the Everyone account or whatever, then there is a security hole. Since this whole aspect of NT seems poorly documented, there is really no telling how many security holes there are in this area.
Many users have asked how to secure a shared workstation so users cannot do any damage to the machine. For example, a workstation in a computer lab at a university. As described above, there is no way to secure the registry. The file system can be secured by setting the entire drive to the following permissions:
SYSTEM full control
Administrators full control
Everyone or Users read only
Permissions should then be reset on the %SYSTEMROOT%\SYSTEM32\CONFIG dirctory as follows:
SYSTEM full control
Administrators full control
CREATOR OWNER full control
Everyone or Users add permission only
These settings allow users to create a profile, but prevent them from reading other users profiles, to avoid the security issues described in the section on Profiles contain sensitive information.
Permissions should also be reset on the TEMP directory (C:\TEMP or whatever) as follows:
SYSTEM full control
Administrators full control
CREATOR OWNER full control
Everyone or Users add permission only
These settings allows users to use the TEMP directory, but avoid problems with users being able to read temporary files containing sensitive information that were created (and never deleted) by other users. Even if user remove files with sensitive information from the temporary directory, there is the issue of permissions being retained when a file is moved instead of copied (discussed in the section on Permissions set improperly). So the permissions on the TEMP directory should be set so initial permissions on a file are restrictive. Users can later make the file world-readable if they want to.
There are other files and directories to which users of a shared workstation may need write access:
The above list is not all-inclusive. You can enable failure auditing on all files and then examine the audit logs after making the most of the file system read-only to determine what files users need write access to. You can also use the Somarsoft DumpAcl program to dump and print file permissions prior to making any changes.
A WinWord document can contain a macro which runs when the file is opened. These macros can perform very powerful operations, including file i/o, sending mail or calling Win32 services. So a malicous user might ask another, unsuspecting user to read a document the first user wrote. This document contains a WordBasic macro which runs when the document is opened. The macro copies all files from the unsuspecting user's personal directories to a directory to which both users have read and write permission. The macro then sends mail to the malicious user notifying them of what happened. The document may take a while to start up, but the unsuspecting user assumes this is because the document is long. The malicous user later deletes the WordBasic macro from the document and notifies the unsuspecting user to replace any copy they made, so that all potentially incriminating evidence is destroyed.
It is also possible to write the macro so it calls a user written DLL that does something useful, as well as copying files and performing other hostile acts. This DLL might be large and complicated so that it would be very difficult to disassemble it and prove that it was doing something wrong. Even if you were able to prove that the DLL was accessing your files, the author could say this was due to a bug in the DLL. If you demanded the source from which the DLL was compiled, the auther could give you some modified source. When you pointed out that this source could not be used to build the DLL exactly, the author could reply that the source had been modified to fix bugs since the DLL was originally built, which is a perfectly reasonable explanation. By using a DLL in other words, there is never any incriminating evidence.
There are other programs besides WinWord which can create files which contain embedded macros which execute automatically when the file is opened in the creating application. For example, Microsoft Access and Lotus Ami Pro (these are just the programs I am aware of, I am sure there are many others). Also, Postscript files, believe or not, have file i/o capability. So if you open a postscript file in an interpretor, it might go out and modify any files to which you have write access. Also, Windows Help files (.HLP extension) can call DLLs (typical use is to customize the Help program in some way).
So, suppose you receive a package containing a .HLP, .EXE and a .DLL file all together. You want to browse the .HLP file to see what this package is all about and whether you trust it enough to run the .EXE file. You assume the .DLL is called by the .EXE only. When you open the .HLP file, the .DLL is executed and it's too late if you decide the package is untrustworthy.
Some Internet Web browser are setup to automatically start up the application associated a document suffix. So if you click on an URL ending in .DOC, that file will be fetched and WinWord will be started with that file as the command line. If that file contains a macro, it will be run. If that macro is malicious, too bad for you.
WinWord and Access both allow the user to hold down the shift key when opening a document to prevent any macro from running. It is difficult to get in the habit of doing this (I am speaking from experience), especially when most of the Word or Access documents you open are your own, and therefore known to be safe.
Why authors of programs feel the need to include powerful embedded macro languages is something I really don't understand. It is possible to accomplish most of what embedded languages do using DDE or OLE automation. The advantage is that the end user learns one scripting language environment and then applies it to different applications, as opposed to learning a new language for each application. Microsoft has decided to include VBA in all of their products, which reduces the amount of learning to some extent. But why, I ask, not just provide good OLE Automation capabilities so we don't need embedded macro languages at all, but can instead use a separate Visual Basic program?
In any case, if it is absolutely necessary (for political or marketing reasons) to include an embedded scripting language in an application, then users should be allowed to set an option in the application so that they are prompted before any macros are run (e.g. "this document contains an embedded macro. Do you want to run this macro?"). There should be no way for the document to override this option and the option setting should be persistent (saved in a .INI file or the user's registry profile). If absolutely necessary, the application can be designed so that if the user refuses to run the macro, the application will refuse to open the document.
(In response to the WinWord Template virus, Microsoft has created a patch for WinWord, which will notify you before running any autoexec macros. This patch is available as self-extracting file WD1215.EXE from http://www.microsoft.com/kb/softlib).
Interesting Note (5 May 1995). The big news this week is the Good Times mail "virus". This is a hoax which alleged that there was a way to write a mail message such that if you read the mail message, all your files would be deleted. Users reading this hoax become frantic that they can no longer read any mail without endangering their system. Actually, there is an element of truth to this. If the mail message included an attached Word document, then reading that attachment might cause a macro to be run which deleted all your files. These attachments can be sent using SMTP MIME or Microsoft and other propertiary mail systems.
WinWord Template Virus (28 Aug 1995). In case you haven't yet heard, there have been press reports of a virus written in Wordbasic. This virus does some fairly innocous things, like make you save the current document as a template. It could have been much worse. Microsoft is scrambling to put a virus scan and removal program out on the BBS's. We would be better served by an option in WinWord which, when enabled (and enabled should be the default although for marketing reasons it won't be), would cause WinWord to prompt for user authorization before running any WordBasic macros.
The SMB file and print server protocol used by NT is much more resistant to impersonation and session hijacking than the NFS file sharing protocol used on Unix. This is significant since NFS is one of the biggest security weaknesses on Unix.
It is remotely conceivable that a gateway machine could hijack an SMB session and then read/write any files to which the true user of that session had access. However, the likelihood of this happening is very small, since true gateway machines are seldom used on LANs due to performance reasons. If the machine attempting the impersonation or hijacking is merely a node on the same Ethernet or Token Ring as the client and/or server, then it would probably be very difficult to perform the impersonation or hijacking. In particular, it would be difficult to get packets routed to the impersonating machine instead of the true destination machine.
In any case, the much more relevant security risk is that user data is transmitted in the clear and so can be easily read by any computer on any LAN over which the data passes. Remember that if you connect to a remote network drive over the Internet or other insecure connection, you are passing data back and forth whenever you read or write a file on the network drive. File manager gives the illusion of the data being local, which makes remote files easy to use, but which can also lead to security breaches.
This risk of eavesdropping does not exist for logons passwords, since these are never transmitted in the clear over the network, but rather a challenge-response protocol is used instead.
In the long run, it would be nice if Windows NT were designed so that all SMB protocol data passed over the network was automatically encrypted, using a key which was randomly chosen for each NetBios session. No directly competing operating systems have this feature and, until some do, it is unlikely NT will. If you have a need to transmit data over an insecure network and you want to be protected from eavesdroppers, you will need to use some sort of encryption. For example, there are router boxess that can encrypt all TCP data, but not the IP header which is used for routing. Put one of these routers at two sites and configure with the same key all data passed between those sites with be secure. You are still open to traffic analysis, however. Traffic analysis is a concern, for example, when an undercover spy wants to send reports back to the home office, or similar scenarios.
There may be some special network cards (with NT drivers, please) which perform on-the-fly encryption, to avoid the problem of eavesdropping on a LAN. Presumably the netcards would have to be configured by an administrator to contain a shared key. Manufacturers of such netcards who would like a link, please drop me a note.
Some users put their userid and password on the command line of the program manager item, for example for Microsoft Mail. This way they can start mail by just double-clicking the mail icon, without having to type in their password. This password will be embedded in the user profile.
The local user profile is stored in %SYSTEMROOT%\SYSTEM32\CONFIG and also on a file server share, if a named, domain-wide user profile has been assigned for the user. Permissions on these directories should be like:
SYSTEM full control
Administrators full control
CREATOR OWNER full control
Everyone or Users add permission only
This is how permissions are initially set on %SYSTEMROOT%\SYSTEM32\CONFIG. Since CREATOR OWNER has full control, each user will have full control of their own profile. Since Everyone and Users have only add permission, they will be able to create a profile, but won't be able to read other users profiles.
In some cases, such as with 3270 emulator programs, passwords are included in keyboard macros (so the user can use F12 or whatever to initiate the entire logon sequence). These macros may be stored in the user profile or a file. If a file, users should be warned to make sure the directory where this file is stored is not world-readable. This is primarily a concern on shared workstations.
Supposedly, requiring a user to press Ctrl-Alt-Delete to bring up the login screen protects against application level trojan horses, since the operating system always traps this key sequence. However, it does not protect against a trojan horse which has some cooperation from the keyboard device driver nor from a DOS program, masquerading as NT.
A DOS trojan horse would be particularly easy to write and install, provided the NT workstation allows booting from the floppy drive without a hardware password, or this hardware password can be circumvented, somehow. Once the DOS trojan horse program had captured the user's password and transmitted it over the network to the malicious user, it could throw up a fake blue screen of death, alleging some driver problem. The user would call the network administrator, the problem would go away after a cold reboot, and the incident would be dismissed as an NT or hardware fluke and would soon be forgotten.
If a password is short and obvious, then it can be guessed. If it is written down in a notebook, it can be discovered. So pick a long password, consisting of a mixture of upper and lower case letters and punctuation, never write it down, and change it often (but not so often you feel the need to write it down). This is all well-known, but so important that it is worth repeating nonetheless. Finding someone's password written down is the lowest-tech way to break into a system, but unfortunately also the most common.
NT shares the %SYSTEMROOT%\SYSTEM32\REPL\EXPORT\SCRIPTS directory, so that users can read their login script during login. Normally, all of the scripts are readable by Everyone. So be careful what you put in these scripts and this directory. Other special shares are created by other installed services, such as SNA server or SMS. Use Somarsoft DumpAcl to dump a list of shares and their permissions. And examine the permissions on the directories underlying the shares. Remember that the final access permission on a shared directory is the intersection of the share and NTFS permissions. So while you are setting permissions to restrict access, be careful you don't unintentionally completely remove access.
Many of the internet Unix breakins occurred when someone discovered a bug in a TCP/IP service and took advantage of this bug to break into the system. For example, the infamous Internet worm took advantage of a bug which caused the stack to be overwritten if the finger daemon received bad input. Obviously, you should try to only run services which do not have bugs. However, the danger if there is a bug is greatly reduced if the service runs under an ordinary user account with restricted permissions, instead of under the SYSTEM account (which corresponds to the Unix root account). So, for example, run your SMTP service under an smtpuser account, and give this account limited privileges, instead of running it under the SYSTEM account.
If you are not familiar with viruses, there are many good books on the subject. NT is better secured than DOS from viruses, provided you normally run under an ordinary user account (not administrator), and keep most system files protected against modification by user accounts. NT is also secure against boot sector viruses, which are the most difficult to eradicate, provided you never boot with a floppy in the drive, since NT does not allow non-privileged programs to write directly to disk.
A trojan horse (as I define it), is a program which secretly does something "bad" at the same time it openly does something "good". For example, a program might openly provide an interface to an online service, but secretly transfer private files to/from your computer while you are logged on.
Trojan horses are probably a much greater long-term threat than viruses. Viruses typically only destroy data in a fairly crude and therefore noticable way. Since the damage is soon noticed, the data can be recovered from backups (assuming the network administrator is doing their job properly). A trojan horse program, on the other hand, might perform very subtle damage, which might take years to notice. For example, it might search your network for files containing currency values, and then modify some of this values. Or the trojan horse might leak private data to the outside world, which might never be noticed.
The best precaution against viruses and trojan horses, is to treat an unknown program similarly to how you would treat a new business partner. Namely, watch for subtle clues of suspicious behavior, check references, run a credit check, don't give the person a blank check the day you meet them, etc. You should treat an new program with the same degree of caution.
Anyone who has physical access to a machine can read file system data by either reinstalling NT (the installer can pick the initial Administrator's password and Administrator can read all files) or booting from a DOS floppy and reading raw sectors using a low level disk utility. In both cases, the user would need access to the floppy drive. On many machines, the floppy can be disabled via the BIOS. There are two ways to get around a disabled floppy:
These techniques require opening the computer case, so there should be no risk for machines stored in open areas where opening a case would be immediately noticed.
If the case can be opened, then you will need to encrypt data on disk. There are various products which allow you to do this, with varying degress of user-friendliness and transparency. (Any manufacturers who would like me to list their product and add hypertext links to their Web pages, just drop me a note).
If you need military grade security, it should be noted that fragments of any file that is stored unencrypted in memory can be written to the paging file. So software encryption products will not be sufficient in this case. What you need instead is a disk controller which encrypts data on the fly as it is transferred between memory and disk. Typically, the user would be prompted for a password by the disk controller BIOS during cold boot. An example of where military grade security is needed is a embassy which contains secret data on PCs. These PCs might fall into the hands of a hostile intelligence agency with adequate resources to extract information from the fragments of data in the paging file. For most users, such military grade security is not really necessary.
It is obvious that to perform a backup, the operator needs to be able to read all files. What is not obvious is that tape need not be involved. It is trivial to write a program in C which takes advantage of the backup right to read any file in the system. So be careful of who you give the backup right to. Users who have both backup and restore rights can read any file, modify it and write it back, or they can take ownership or change permissions.
User Manager is used to assign rights to users. There is an option in User Manager to audit the use of user rights, and this should include the backup and restore rights. However, because of a poor design of the audit logging mechanism, exercise of these rights are not logged unless a registry value is set as follows:
key : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa name : FullPrivilegeAuditing type : REG_BINARY value: 1
This issue is further documented in the NT 3.51 resource kit.
The administrator can take ownership of any file and thereby obtain read/write access to it. Some users have complained about this aspect of NT, which they view as a security hole. In fact, this same issue has arisen in all previous operating systems, including mainframes and other computers which are traditionally viewed as secure. There is no magic solution.
Some policies that might lessen the risk from rogue administrators (and other users) include:
These are similar to the procedures that are used in such situations as securing jewels in a bank vault, or guarding secret military plans. It goes without saying that it can be expensive to implement the procedures described above.
Note that services which run under the system account and device drivers also have essentially unlimited powers. They can read/write any file, establish network sessions in the background and thereby transport data out of your network, create accounts, etc. See also the section on viruses and trojan horses.
The NT backup program does not encrypt data on tape. So anyone who has a tape can read it on another machine on which the user has restore privileges, such as their personal NT workstation.
Microsoft does a good job of warning people about the fact that FTP passwords are transmitted in the clear. Especially for machines connected to the Internet, it is probably best to allow only anonymous FTP, so that no one ever attempts to transmit a password to your machine over the internet. If you FTP or Telnet from your machine to another machine on the internet, the same warning applies: any password you enter or any data you transmit, could be intercepted by other machines on networks over which the data is passed.
When using the FTP server that comes with NT, the home directory you specify for the FTP service is only the initial current directory. Ftp users can change their current directory. So if you specify a home directory of c:\ftp, any ftp user can change to c:\ and thence change to any subdirectories under c:\. Normal NTFS permissions will apply, of course, to whatever account the ftp user is running under. If you don't want ftp users to be able to see the root directory of your primary partition, you should create a separate partition for ftp and then configure ftp so that it can only read and/or write to that partition.
Note as of January 19, 1996. The new Internet Server that is currently in beta test has a more secure FTP server. This FTP server will eventually replace the one that is builtin to NT 3.51.
The possibility of outsiders breaking into a system is, for whatever reason, the security issue most people concentrate on. In reality, you are most likely to suffer serious computer related losses due to natural disaster (such as a hard disk failure) or from internal theft or misuse of data (for example, a store clerk stealing customers's credit card numbers and selling them to criminal organizations). Don't get so wrapped up with trivial issues (like how some computer science student found a hole in the 40 bit Netscape encryption scheme - big news of Sep 21, 1995) that you neglect the bigger computer security context. This is obvious, but worth repeating nonetheless.
The really valuable data on a computer system is what is produced by applications and stored in file and databases. It is very important to write and install these applications with an eye on security. It does no good to follow all the guidelines above and then have a database setup in such a way that anyone with an account can read the entire database. Or to have a transaction processing monitor which runs under a privileged account and allows unprivileged users to submit requests that give them access to the entire file system.