1.0 Microsoft WindowsNT

My goal is to offer a setup that will be reasonably secure even if not protected by external security measures such as firewalls. If you insist on using LanManager™ style networking on the unprotected Internet, I seriously question your sincerity. (Doesn't stop DISA from doing it, however) Unfortunately, Microsoft's networking model is conveniently built-in and all too many products will not function without it, or are unduly difficult to use in a non-standard manner. In Appendix ??? I will outline some ideas you can use in the event your company absolutely insists on running Microsoft networking. But you must have a competent firewall product and equally good administrators.

In this chapter we will build a NT box that will serve as an Internet server or workstation platform hosting webservers, databases, middleware or simply endusers. I consider certain assumptions to be fundamental:

Purmit me to make some important clarifications before we get started. In the course of this paper I will make mention of running processes as normal users or in a "sandbox". While not to be confused with the Java security model, I can not invoke the Unix concept of chroot(8) jails since NT has some rather significant drawbacks. The proper mental picture should be of a school yard sandbox that has 6 inch high sides to retard the sand from scattering all over the place. Without resorting to serious kernel hacking and design overhauls I think this is the best we can do at this point.

In order to run a program that among other things opens socket connections, (XXX - only priv ports?) it must execute as a user in the Administrators group. Under NT4 there is some additional hanky-panky going on which manifests itself as a bogus "access denied" error to \winnt\system32\user32.DLL. I would appreciate it if somebody could enlighten me as to it's true cause.

So what good is this entire exercise when an attacker is able to get an administrative "shell" on the machine? Not much, unless you emasculate the Administators group and replace it with something else. This means reowning the entire filesystem and methodically revoking user rights. Believe me, it's not a fun task with a product that fights you every inch of the way. Since Microsoft saw fit to hardcode references to Administrators into such tools as the disk administrator and event viewer, we are faced with some more hurdles. Alas, (XXX - insert name here) tells me that the ability to take ownership of objects can never be 100% removed from the Admin user or ??? is it the admin group? [XXX - I need to test this] Thankfully, in a workgroup environment you can afford to leave these advanced settings pretty much alone and instead focus on the filesystem.

By default, services run as system level processes. In the interest of exploring other less drastic alternatives, one can instead opt to cripple LocalSystem's ability to walk the disk. While simpler, this special user is the equivalent of root on Unix and can with a few judicious system calls invoke "god" mode (actually backup/restore privilege) and blithly ignore any constraints. The other glaring problem with this route is that compromising just one service means you can readily attack the others. I can envision a scenario whereby a hole in IIS leads to altering the onboard Oracle database files or worse, stealing the connection scripts and associated passwords. This is one more reason to take the distributed approach and have one machine do exactly one task.

1.1 Disk Preparation

Both for management simplicity and to protect against buggy software, I encourage the practice of dedicating a separate partition just for the NT operating system. I would further separate user writable areas such as web content and home directories from the partition holding server binaries. Some may regard this as extreme, but exploited software is often unable to cross partition boundaries. Be advised that numerous partitions on one physical drive have a negative impact on performance. Even in these days of massive hard disks, I find 250mb to 500mb SCSI disks to be ideal for just this reason.

Your typical system partition will happily live in less than 128mb unless you need enormous amounts of swap space. It should go without saying that all filesystems must be formatted NTFS but some organizations continue to use FAT for some inexplicable reason.

1.2 OS Installation

WindowsNT has received much hype regarding it's C2 rating and enterprise readiness. Many government agencies have jumped on the bandwagon having believed the vendor's and media claims. When addressed from a practical security context, NT rivals Irix and Solaris in it's utterly lax configuration out of the box. Some of the more pernicious problems include:

In a networked environment where attempts to gain unauthorized access are to be expected, it is necessary to make considerable modifications to the system. Unfortunately few sites bother to reconfigure their machines before deployment.

Whenever possible use the Workstation™ version of NT as it's a whole lot cheaper, doesn't include a lot of extraneous junk, and is every bit as capable. I run the following products on it without reservation:

Aside from other BackOffice™ products, I have yet to find a package that will not work on stock NTWS. It's particularly notable that so far, all non-Microsoft products can be rather trivially "sandboxed" whereas those from the creaters of the OS are nearly impossible to do so. I guess we can tell who has the better or at least more careful programming talent...

Microsoft's vigorous FUD (fear/uncertainty/doubt) campaign notwithstanding, there are no significant differences between the NTWS and NTAS offerings except for a couple of registry entries, some bundled software, and a handful of tweaked administrative utilities. Think of it as an $800 "plus pack for NT." O'Reilley's website has a good paper on the subject as does Windows NT Magazine. [Thanks to Dr. Russinovich of Open System Resources and NT Internals for doing much of the core research on this issue.]

About the only thing I miss from the Server™ version is the built-in RAID support, but for less than it's pricetag you can buy yourself a dedicated controller that is far better than any software solution. A note from Paul Ashton states that windisk.exe uses the Product Type registry value to determine whether or not to show the Fault Tolerance menu. I recall attempting this back with v3.51 but there were some RAID specific DLL's missing so it didn't work. A program called ftedit.exe (part of the Workstation Resource Kit) may offer a solution but I have neither confirmation nor a link. (XXX - the old NT Internals purhaps?)

If I may digress for a moment to rant on the state of the industry...

I find it quite disturbing that so many MIS groups and consultancies embrace Microsoft products not on their merits but simply because everybody else is doing it. It's the same mindset that not too long ago said you could never be fired over buying IBM. It's not like nobody else has good product! If free is your ticket and NT your platform of choice, IBM's server which is derived from CERN's does rather well and supports NSAPI. There was a rumor that Apache was being ported. If not, with one of those unix-on-NT products it just might be possible.

In my biased view, Unix is the only time tested operating system that is built to handle the load and offer Internet services. I highly recommend OpenBSD for that team's remarkable track record in quashing system bugs in a proactive manner and it's wide ranging hardware support (both RISC and x86). They put commercial unix vendors to shame. Unfortunately, some of the more nifty software is only available for Windows NT™ which forces businesses to use this still immature platform in mission critical situations. That is why I have made the effort to produce this paper.

Redmond's obvious ploy is to force people into using their offerings by virtue of price and shenanigans in licensing terms. Once they convince you to buy the server version why pay more for similar functionality, right? I doubt the extra $100 or two for a competing product will break your budget, however, and quite frankly the others are better in significant ways. I just read a cost of ownership report by Business Research Group that showed Macintoshes made the best web servers. [Thanks Macintouch] A column by ??? in ComputerWorld (vol?) entitled "?unix by the numbers?" made a convincing financial argument for Unix.

And now back to the business at hand...

Boot the installation media and at every opportunity select the custom option, setting up the partitions or disks as outlined in the previous section. If you opted for Server™, choose the standalone option. Do not install any printers, readme files, wall papers, or screen savers as there is no need for them. The same holds true for the sound effects, multi-media software (planning to jam to the latest Rolling Stone CD while at the server console?), document viewers, messaging components, clocks and the rest of the accessories. Notepad will come in handy, so be sure to select that if using v3.51. Version 4.0 installs editors (even edlin!!) regardless of your wishes.

The screen saver issue made a bit of a splash some months back on NTSEC when people complained about speed on servers dropping precipitously. It was discovered that the administrators were running CPU intensive 3D screen savers. That is just plain dumb. If you're going to leave the station unattended, the very least you can do is give it the three finger salute and lock the console. If monitor burn-in worries you, turn it off.

1.2.1 Networking (1/2)

Early on in the installation process you will be prompted to make selections for the networking components. Microsoft's overhelpful wizard precludes you from installing only what you really want, but I guess the expensive usability studies showed that people were in need of benign assistance and hard coded defaults. If you are building a RAS box all bets are off from here on out. I've never used dialup networking on NT4 and as the following sections illustrate, I systematically delete these components. If there is enough interest and I have the time, I may explore this aspect of NT. In the meantime, a cabled connection is assumed. As you work your way though the dialogs:

As an aside, it seems some people think that when a machine joins a domain, the local admin account get's subsumed by the domain one. Hardly the case, but I've included this factoid for those who are reading this section as linked from my workgroup companion paper.

Install any additional Microsoft networking components like the DHCP service but please be extremely cautious as to your selections. I have a simple word of advice for those who intend to host mail, ftp, dns and related services on NT, DON'T! Unix does a vastly superior job and has done so for decades. If you simply can't bother yourself to learn Unix or don't want to hire a knowledgable and competent contractor to do it for you (hint: I'm taking job offers), at least treat Microsoft's offerings with great circumspect, much as you would the plague. They are probably the worst implementations known to man. Instead, for a very reasonable sum you can get commercial products that are pretty much direct ports from Unixland. In some cases, the Free Software Foundation and other sources offer free versions of these cornerstone Internet technologies. (XXX - need links to products like sendmail/dns/dhcp, Vixie etc. here - reader submissions are welcome!)

For something as simple as a database or web server though, you don't need anything extra. Since it will take a fair amount of time to configure the machine properly, I recommend pulling it's network connection if you have not done so already. Reboot and log on as Administrator. Congratulations, the stock installation is complete and we are now ready to get down to business.

1.2.2 Cleanup (1/??)

Just as some wise sage posted in his .signature, "Managing complexity is too hard, simplify!" I also believe in removing the large amounts of cruft Microsoft bestows upon your disk without your say so. Unlike other more mature operating systems in which elimination of large sections of the file tree are pretty safe and straightforward, NT is anything but, forcing one to contend with all of those DLL's. Finding out which to delete was an exercise in extreme patience. I've had to reinstall NT more times than I care to count after blowing away the wrong thing. Thankfully, NT4 is a bit more responsible and compartmentalized than v3.51.

By way of the Network control panel remove the following:

Unfortunately there are some version and product specific dependencies with regard to user management tasks that limit when the last 2 can be removed. In general, leaving the Workstation service installed but disabled allows the administrator the most flexibility. However, I still recommend removing everything since one can readily copy over the NTWS version of the user manager and thus sidestep NTAS' limitations.

Table 1 - NTWS and Account Managment
Workstation Server
Disabled Removed Disabled Removed
GUI User + Y Y Y Y
Y Y Y Y
Group + Y Y Y Y
Y Y Y Y
NET User + N N Y Y
Y Y Y Y
Group + Y Y Y Y
Y Y Y Y

Table 2 - NTAS and Account Managment
Workstation Server
Disabled Removed Disabled Removed
GUI User + N N N N
Y Y Y Y
Group + N N N N
Y Y Y Y
NET User + N N Y Y
Y Y Y Y
Group + Y Y Y Y
Y Y Y Y
Microsoft User Manager. NET command line.

The list below is far from exhaustive and is largely optional but strongly encouraged nonetheless. If anyone has a more complete collection of candidates, feel free to contribute your findings. If deleting the following items strikes fear into your heart, I suggest making a trash dirctory and stuffing them in there so that if you need them back, you have that option. So far this sounds rather alarmist and is deliberately so. I will not be held responsible for anyone's inoperable server. Suffice it to say I've built many a machine without these components and nary a problem has surfaced. When building a highly modified machine, making periodic filesystem snapshots to tape is a good idea.

XXX -Note to pre-release reader, this ain't gospel yet!
Directories Files Registry Devices Environment Desktop %SYSTEM_ROOT%\*.cur (Mouse cursors - primarily NT3.51) %SYSTEM_ROOT%\clock.avi lots of other stuff...DDE, RAS*, various subdirectories, REPL, WINS, DHCP, media rsh, rcp, rexec, rlogin, tftp, posix dll?

Finally, we have a system that is starting to resemble the baseline.

1.2.3 Service Packs

In case you've missed the regular bug reports in the computer media, NT has lots of problems, some quite serious. It is therefore paramount that you studiously keep up with the steady stream of service packs. Even with the bug fixes alone, Microsoft's track record in the reliability arena is less than steller so be careful to test them before getting yourself into trouble. After the fiasco that was SP2 for NT4, Microsoft has pledged to do a better job. I hope they do. In the meantime, this ever security concious behemoth of a software firm has yet to provide MD5 hashes or PGP signed binaries to testify as to their authenticity. (hint: "The clue meter is reading zero" - Dilbert® by Scott Adams)

At this point you should be completely done installing Microsoft software. If not, (IIS anyone?) better get around to it and (re)apply the service packs. While no guarentees can be made for third party products, most aren't likely to replace key parts of the OS. Just to make sure, however, we'll reapply the service packs again after all needed server and client software is installed. The assumption here is that Microsoft should be the authoritative site for system patches and that any other sources are suspect. There are rumors that NT5 will include a mechanism by which administrators can lock out applications from mucking with system DLL's. Even with this band-aid, I remain convinced this shared DLL stuff is a hellish nightmare.

1.3 User Accounts

With the User Manager, create all of the user and group accounts you'll need. Now this may not be possible particularly if it's an Internet access terminal for endusers or a server doing user authentication with changing sets of customers. Since I build strictly guest terminals and anonymous servers, the problem isn't acute. Similarly, many Unix tools that have migrated to NT use their own databases modeled after the standard /etc/passwd format. The issue at heart is the inability of NT to create user and group accounts without one or both of the workstation or server modules. Combine that constraint with the goal of removing the services and the situation becomes complex. The following table helps to clarify the relationship.

Table 2 - User Manager Dependencies
[XXX - does it need to be running?] If you install the Server product it will likewise refuse to create accounts without the Server module. Even using net user /create doesn't work. (workarounds anyone?) Likewise, IIS won't install without it but apparently doesn't have to be around after the fact. Microsoft genius at work I guess. (XXX I forget if all of this is this true? check notes)

For my work and the purposes of this paper:

  1. create a wheel group - real administrators
  2. create a daemon group - collection of server software
  3. create another administrative account to replace the original
  4. (optional) rename built-in Administrator - it will slow down console hackers
  5. assign Administrator and new admin accounts to wheel group
  6. assign server software "users" to daemon group
  7. specify each of the preceeding "users" a distinct home directory - ex. Oracle = d:\oracle73; FastTrack = d:\fasttrack

Add the built-in Administrator and new admin accounts to the wheel group. Similarly, place all server application "users" in the daemon group. If this latter set is part of the Users group, remove them from it.

This is as far as I've gotten folks, please be patient. thanks.

The rest of the stuff below is a rather munged collection of stuff from the previous iteration. Please ignore for now.




Accepting for a moment that you ... go to the Networking control panel and proceed to remove the Workstation

When presented with the network software options, remove everything but TCP/IP Protocol and Workstation. Ignore the warning dialogs as we have no desire to use Microsoft’s network model. Do NOT join a domain. You can accept the default workgroup or change it’s name to something more appropriate but hopefully doesn’t exist anywhere accessible over the network. The Workstation module, however, is unfortunately needed for IIS to register itself. Configure the IP address information according to your site being sure to OMIT any WinS items.. On the "Advanced" page, deselect "Enable LMHOSTS Lookup." Checking the bindings page should show 2 entries: 1 each for TCP/IP and Wins (Client).

1.4 ServicePack 4

Download and apply the latest NT service pack. After the requisite reboots, you should now have a usable workstation. Consider backing up the entire file system so you can come back to this baseline if needed.

1.5 User accounts

Create 2 local user accounts "webmaster" and "ftpadmin" for the purposes of administering their respective services. Set a good password for all accounts to include Guest if that is your choice for the anonymous web and ftp user. Otherwise the account should be disabled. Give each user their own home directory except Guest who should have none. Delete the c:\users\default directory as it is no longer needed. Additionally, check the Guest account checkbox for "User Cannot Change Password". All Groups should be empty except for the Administrators group which should include the Administrator account.

1.6 Account Policy

Set passwords to expire in a reasonable amount of time: between 30 to 60 days are good values. Passwords should have a minimum aging period and be at least 6 characters long. To hinder password attacks enable account locking with reasonably long time-outs. 3 failed login attempts within 30 minutes with a lockout of 1hour are decent sample values.

1.7 User Rights Policy

Access this computer from network NONE

Back up files and directories Administrators,

Backup Operators

Change system time Administrators

Force shutdown from a remote system NONE

Load and unload device drivers Administrators

Log on locally Administrators, ftpadmin, Guest, webmaster

Manage auditing and security log Administrators

Restore files and directories Administrators,

Backup Operators

Shutdown the system Administrators

Take ownership of files or other objects Administrators

1.8 Audit Policy

Without auditing, an administrator has no way of tracking user activity. I recommend checking all categories except File and Object Access (success) and Process Tracking (both) as they produce large amounts of data. Even with extensive auditing, it is essential that the administrator daily review the logs, both to establish a baseline of activity and to look for anomalies.

1.9 Directory Permissions

All directories are owned by Administrator. If the directory is not listed below, it probably should not exist. ‘Administrator’ is interchangeable with the local Administrators group but ensure the local Administrator is the only member. Substitute the anonymous FTP and WWW username for Guest below. The permissions are somewhat minimalist and may be too restrictive depending on your environment. This applies particularly to the Administrator account which may benefit from having Change rights in certain trees. Note that these permissions are the end result. You will need more relaxed rights in order to create the various directories and install software and updates etc. I recommend setting the permissions after you are sure everything is installed to your liking.

 

Directory User Rights

Delete config.sys and autoexec.bat. You shouldn’t need them.

 

C:\ Administrator List

ftpadmin List

System Read

webmaster List

 

C:\users Administrator List

ftpadmin List

webmaster List

 

C:\users\admin Administrator Change

 

C:\users\ftpadmin ftpadmin Change

 

C:\users\webmaster webmaster Change

 

C:\temp (optional) Administrator Change

ftpadmin Change

webmaster Change

 

Depending on your system, consider giving the administrator Change rights to win.ini, system.ini, and windisk.ini. The default location of backup.log resides here. Consider redirecting it to a different path or grant Change rights to it. Alternatively give Administrator Add & Read at the directory level with Creator Owner set to Change as done below.

 

C:\winnt35 Administrator Read

ftpadmin Read

System List

webmaster Read

 

C:\winnt35\repair (optional) Administrator Read

 

Central font repository.

 

C:\winnt35\system Administrator Read

ftpadmin Read

System Read

webmaster Read

 

Only if you are using scripts needing system DLLs should Guest have any rights. I find windows programs’ placement of DLLs in the system tree to be abhorrent. Unfortunately, MS hasn’t seen fit to fix their stupid design. When applying updates or installing software, it will most likely be necessary to relax Administrator permissions to Change. The permissions below permit the Administrator to run the backup utility as the program relies on creating temporary files in this tree. If you use a smarter backup tool or don’t do backups, change Administrator to Read and remove the "Creator Owner" entry.

 

C:\winnt35\system32 Administrator Add & Read

Creator Owner Change

ftpadmin Read

Guest Read

System List

webmaster Read

 

CMD.EXE likes to write to this file.

 

C:\winnt35\system32\cmos.ram Administrator Change

ftpadmin Change

webmaster Change

 

I have no idea what this directory does. It’s probably safe to delete

 

C:\winnt35\system32\cache System Change

 

This directory keeps system and configuration logs. Unless you want non-administrative users to use EventViewer, revoke all rights, otherwise grant them READ access to the .EVT files. Since the log files are locked on boot, only System really needs to access them.

 

C:\winnt35\system32\config Administrator List

System Change

 

Permissions can probably be narrowed to Special [RW] but are untested.

 

C:\winnt35\system32\config\*.evt Administrator Change

System Change

 

Used only if DHCP is enabled. These permissions should work but are untested.

 

C:\winnt35\system32\dhcp Administrator Read

System Change

 

Administrator doesn’t really need this unless you elect to later edit the ./etc files. (see below)

 

C:\winnt35\system32\drivers Administrator List

System Read

 

Administrators should use DNS but in those instances where access to the HOSTS file is needed for name resolution. Note ftpadmin and webmaster can’t actually list the file (since they can’t traverse the directory tree) but the resolver reads it as the current user. System may not need access but I’m not sure. If edits to HOSTS etc. are needed, one must give Administrator Change rights on that file for the duration.

 

C:\winnt35\system32\drivers\etc Administrator Read

ftpadmin Read

System