Securing Windows NT/2000 Servers for the Internet

Windows NT/2000 in the Perimeter Network

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.

Least Privilege

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,^[17] 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,^[18] and to call the required Win32 APIs it needs to run at very high privilege level.

It’s unfortunate^[19] 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.

Exploiting Buffer Overflow

The reality is that there are bugs in all software. It’s usually not a problem if an application breaks or misbehaves under some rare circumstances—let’s say 0.01% of the time. However, if you know how to force an application to misbehave or to crash, you can use this knowledge to force 100% failure. As a result, a malicious user can cause a crash (denial of service) and even execute arbitrary code on the system in the security context of the broken application. For this reason, it’s very important that exposed services in the perimeter run with the least privilege possible.

A common way to break poorly written code in an application is to overwrite code segments in the stack by feeding the application long strings (URLs, for example) or other data. To keep such attacks from breaking your applications, make sure that all programs that read input always perform bounds checking (checking the length of input and trimming the strings according to the length of the input buffer). If an application doesn’t do bounds checking, it can crash. If an attacker succeeds in inserting machine-level instructions using an overflow attack, he can execute this code in the security context of the application.

The pointers of the C programming language are mainly responsible for buffer overrun problems. Some programming languages, such as Java™ and Perl, prevent developers from making these types of programming errors.

According to a recent report, ^[20] buffer overflows are by far the most common type of network-based attack (because most network servers are written in C). For this reason, it’s of utmost importance to keep your systems up-to-date with application and operating system patches and service packs.

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.

Figure 1-12. Dual firewall systems and reverse proxy solution

Separate Ports

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).

Microsoft could have done a better job here. It’s virtually impossible to have Windows servers that need to communicate using NetBIOS or Direct Host in different compartments in the perimeter.

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.

Figure 1-13. NT domains in the perimeter

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.

---

^[17] 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.

^[18] Unauthenticated “anonymous” connection threads run as the IUSR_MACHINENAME account.

^[19] 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!

^[20] “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).