Features like discretionary access control, security auditing, and memory protection place the Windows NT core operating system on par (or better) with many Unix systems in terms of local host security. So why do many people claim that Windows is less secure than Unix?
The problem is not really Windows itself; rather it’s the services and applications built on top of the operating system that are the weakest links.
The following sections describe some fundamental principles of secure system design, as well as examine how some of Windows NT/2000’s services and applications stack up to these principles.
A very important principle is that of least privilege. The least privilege philosophy dictates that an application should be designed to run only with the privilege level it needs to execute properly—and no more.
Consider the following question: what privilege level do you need to grant to a web server application? The simplified answer is that the application needs the right to read the data files it serves. Now, take a look at the Internet Information Server’s (IIS) WWW service. By design, it has to run as Local System, the highest privilege level in Windows. IIS does run the actual worker threads with lower rights, but if an attacker manages to break IIS before the security context switch is made, he’ll be able to do anything, including deleting filesystems, starting up a back door, and so on—you get the idea!
Microsoft designed IIS in this way to be able to integrate the web server with the NT security architecture. There’s not much specific security code in IIS; instead, it uses the same access control mechanisms as any other NT process would. The IIS authentication mechanisms use the NT account database. Access to individual files and directories is controlled by NTFS DACLs, just like on a file server. To achieve this level of functionality, IIS needs to be able to start a process or a thread in the security context of the connecting user, and to call the required Win32 APIs it needs to run at very high privilege level.
It’s unfortunate there’s no option to install IIS without this functionality, since most Internet web servers don’t need user authentication, and because of this, could run IIS at a much lower privilege level.
Unfortunately, many Windows applications and services run as Local System. Some of them may not need that privilege level, but it’s the default. Most Windows software vendors don’t seem to be aware of the least privilege approach, or at least they don’t reflect such awareness in their code. As a result, a bug or back door in these programs can compromise the security of your entire machine. If an application is exposed in the same way it is in a perimeter network, it needs to be designed with security in mind. In fact, the top priority in the perimeter is often not functionality or speed—it’s security.
Any application that must run as Local System is potentially a major security hazard. It’s a sitting duck waiting for a new buffer overflow attack (described in the sidebar later in this section) to happen. If you’re running web servers like IIS, one possible solution is to place an application-level proxy in front of those servers. The proxy should be able to verify that any requests to the IIS WWW service conform to the HTTP standards. Any malformed HTTP requests will be blocked in the proxy. As a result, the web server is protected from many forms of attack. The disadvantage of having a reverse proxy as an additional layer of security is that it will impact performance to some extent. You also need to make sure that the proxy solution isn’t a single point of failure if you want to build a highly available site.
The choice of proxy server product depends on your security needs. It may be sufficient to use an intelligent and configurable application-level (or hybrid) firewall. A better solution may be a combination of one or several dedicated firewalls and a reverse proxy server, as shown in Figure 1.12; such a configuration provides additional layers of security.
Another important principle of secure design is to use one (or a few) fixed TCP/IP port (TCP or UDP) per application. It’s good practice to use different ports for logging, viewing performance data, network logon, and so on. This separation makes it possible to implement granular network access control in the perimeter. It’s often a good idea to design an application using this method.
So how does Windows behave on the network? Windows NT is terrible — just about every service uses SMB over the NetBIOS session port (tcp/139). Windows 2000 is somewhat better. Logon authentication is Kerberos (tcp/88 and udp/88). There’s also LDAP (tcp/389) to the Active Directory database. Everything else uses SMB just as in Windows NT 4.0 — either over NetBIOS or over the new Direct Host protocol port (tcp/445).
If you plan to support a large number of Windows NT 4.0 or Windows 2000 servers, you may find that it’s difficult to manage them as separate hosts. It is tricky to have both security and a management platform that scales up to hundreds of servers. It is tempting to use a centralized accounts database (using NT domains) and other NetBIOS-based tools like Event Viewer and Server Manager.
At very large sites (those with 50 or more NT servers in the perimeter), a common setup is to have dual-homed NT/2000 systems with NetBIOS/SMB unbound (deactivated) from the external network interface. The internal network interface is connected to a kind of management network so that the servers can be managed using the standard RPC-based tools in a domain environment. A remote console solution such as Terminal Server is often used to gain remote access to the management network. Figure 1.13 shows such a solution.
If you must run NetBIOS in this manner, you should be aware that it will be extremely difficult to build a well-compartmentalized perimeter. You can’t set up network access control to allow only a certain type of NetBIOS traffic. As a result, you have to consider all hosts within an NT domain as one security zone. In such a configuration, if one server is broken into, there are no security mechanisms that can protect your domain controllers and other servers in the same administrative domain.
NetBIOS was not designed with security in mind and I recommend against using it in a perimeter. However, if you choose to implement NetBIOS anyway, I urge you to implement an extremely secure perimeter using multiple firewalls and a reverse proxy solution. Do not allow any direct connections from the Internet to your exposed services.
 An example of a back door is a shell process (like cmd.exe) that runs with Local System privilege and that can be accessed over the network.
 Unauthenticated “anonymous” connection threads run as the IUSR_MACHINENAME account.
 If you consider the security implications, you’ll realize that an experienced Unix system administrator would never run a web server as root. It’s just not a very bright thing to do!
 “Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade,” by Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and Jonathan Walpole, Department of Computer Science and Engineering, Oregon Graduate Institute of Science & Technology (http://immunix.org/StackGuard/discex00.pdf).