Microsoft

Perhaps the most promiscuous of all OSs, Microsoft’s OS—with its almost weekly and sometimes daily critical security updates—suffers from continuous discovery of security exploits. It is perhaps the worst choice of OS and perhaps one of the most difficult to harden. The list of services on a Windows XP system that can create vulner- abilities to external hacking, starting with Remote Procedure Call (RPC) as possibly the worst offender, would seem to be endless. The ease with which hacker-cracker software and methods can install, launch, and integrate services on the Windows platform is not merely frightening; it borders on irresponsibility on the part of its manufacturers.

But perhaps it is defensible. Windows is a very powerful OS, possibly the most powerful of them all because, with its plethora of available and native services, it is also extremely flexible. A service is usually a component of a Windows application/software. It runs in

the background and usually runs regardless of the actual user account that is logged on to the system. The Code Red and Nimda viruses, in particular, exploited services that were running by default on user machines. Some viruses even install and awaken other services! But the ease with which new services can be installed and started is mirrored by the ease with which most services can be removed, negotiated, or configured. Furthermore, there is a prepon- derance of information available online from sites such as microsoft.com, expert-exchange.com, and annoyances.org. In and of themselves, these sites combine to provide an almost complete guide to configuring and customizing the Windows experience. Regardless, when placing a Windows server between a LAN and WAN as a fire- wall, extreme pains must be taken to apply critical security updates, manage file and system permissions and passwords, and find and subscribe to newsletters that discover and outline the latest security threats. The most common method of an intruder is to first com- promise an exposed vulnerability and then use that “crack” to mod- ify and subjugate additional services. For example, an intruder may crack open the RPC service and subsequently activate or install a Simple Mail Transfer Protocol (SMTP) service for the purpose of sending spam.

Navigating Windows services

Typically, the reason an administrator will choose to use a Windows system as a firewall is more one of ease and familiarity, a marriage of convenience rather than one of logic. Regardless of the reason, though, once the choice has been made, it must be supported. Here is a good place to start. Table 6.1 lists a few Windows services that must be disabled if and when a Windows machine is used as a fire- wall. With more than 60,000 ports and thousands of threats, listing them all would require more pages than there are trees.

Services can be viewed and configured in any Windows 2000/XP machine through the management console by right clicking on My Computer and selecting Management. If a Windows machine is to be used as a firewall, every single service that runs on that machine should be known and understood by the administrator—what its dependencies are, what its risks are, and if there is any chance that the service can be started by a successful crack into the system. It is a daunting amount of knowledge to obtain; Table 6.1 should pro- vide a good starting point. However, this table cannot be said to be

6.3 Selecting an operating system 117

Chapter 6 Startup

Service Port Setting Risk Note

Internet 80 N/A Extremely Do not install, uninstall

Information high if installed

Services

SNMP 161 Automatic High Uninstall/disable Print 515 Disable None Needed by critical

Spooler updates

SMTP N/A Extremely Do not install, uninstall high if installed

FTP N/A Extremely Do not install, uninstall high if installed

Background Stopped Manual or Nuisance Possible software

Intelligent disabled dependencies; disable

Transfer at risk

Service (BITS)

Computer Disable Browser

Kerberos 750–754 Depends Medium Used by VPN technology

Security Disable High

Accounts Manager

SSDP Disable High

Discovery service

Telnet 23 Disable High

Terminal 3389 Disable or High Change port number Services alter port (using regedit*) or

used use at risk

QoS RSVP Disable Some configurations

may depend on this service; it is, however, a protocol service that opens ports on the machine and, as such, presents a security risk

Security Risking Services and Recommended Configuration

Table 6.1

*To access the registry editor, type regedit at the run prompt. In regedit, navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP- Tcp, and alter the value in the right-hand pane to a port value other than 3389. Further information is available online at isaserver.org.

complete because there are many services that run on machines; this list only covers a few services that are known and are extreme risks. And this table should not be used as a foundation for simply secur- ing internal LAN PCs. This table is specifically tailored for a server dedicated for use as a firewall; that is, one that will receive firewall software to further harden the system. In and of itself, removing and disabling services does not a firewall make. When converting a machine for use as a firewall, the recommended procedure is to completely reinstall the OS from scratch. This is primarily because when software has been removed from Windows, it leaves behind

memories—changed settings, modifications to dynamic link libraries (DLLs), executables, and other potentially dangerous file and system changes. It is best to start with a knowable premise rather than an unknowable one.

NTFS

In addition to the security of the ports, there are several other aspects of hardening an OS that should not be overlooked. Typically, most administrators are aware that NTFS allows far greater security of the file system than FAT. Format all drives with NTFS, without excep- tion. Computers on the network that are FAT should be upgraded to NTFS without hesitation.

Services (Windows)

All services, generally, run under a default “system” account. Everything about how a service operates is configurable, including the service “log on.” From the management console of any Windows 2000 or later machine, browse to the services console and right click on a listed service. From the Properties sheet, select the Log On tab, from which the log on can be controlled. Bear in mind, the configu- ration in Table 6.1 is for a dedicated firewall. Some services depend on other services that daisy chain throughout all the services. By clicking on the Dependencies Properties sheet, an administrator can work through any issues that may arise as a result of changing the log on of a particular service.

Windows XP (and Windows Server 2003) offers further under- standing and configuration flexibility through a tool called the Services Controller (SC). The SC provides command line operability of all services and, to some a bonus and others a bane, scriptability.

The first question, upon review and use of this tool, is “Why? Why use this tool and not the perfectly acceptable administrative console?” The answer is that the console has a rather severe limita- tion: It only shows services in three states: stopped, paused, or run- ning. This does not always actually portray the service in its true state, since there are four other modes of operation. Because of this, the administrative console may show that a service has stopped when it is actually “stopped-pending.” The four other statuses are as follows:

■ Continue pending ■ Start pending ■ Stop pending ■ Pause pending

Even the net start command will show from the command line that a service is stopped when, in fact, it may be start-pending. Running SC.exe from the command line will show the true state of a service. This author has experienced a lion’s share of headaches with Event Viewer errors caused by services thought stopped with the “net stop” command.

Further information about the nature of services can be obtained through the command line “portqry” command. This command does not, natively, install to the Windows command prompt. See the section Scanning for Vulnerabilities, later in this chapter, to learn more about how to install and use this tool to assist in the lock down of Windows.

UNDERSTANDING THE STARTUP TYPE OF A SERVICE

Further hardening of the OS may be necessary in cases where the firewall software requires certain services to be at its disposal. But how does one determine which services need to be configured, and how? It’s all well and good to have a list to work from and to see how someone else did it, but without understanding the rigorous principles and without developing the skill to evaluate and introduce new services into the OS, an administrator is without the necessary skills to successfully administer a Windows firewall.

6.3 Selecting an operating system 119

It may seem simple, but it’s not. Things are not always as they seem on the surface, and descriptions provided by user interfaces are not always as straightforward as they may seem. The three startup types include manual, automatic, and disabled, each with its own set of quirks.

■ Manual: Service starts on demand when requested by either a user

or another service or software.

■ Automatic: Service starts at boot up.

■ Disabled: Service is turned off but can be set to manual by any

user or software with the ability and the correct permissions. A better name for this would be “off.”

Thehardened approach involves the complete removal of unnec- essary services, not just the disabling of them. SC.exe, natively avail- able to Windows XP and available to other OSs through the Software Development Kit (SDK) from Microsoft, offers the admin- istrator the ability to actually delete services. Here are some quick tips that will help with getting started using the SC:

■ Run the SC by typing “SC” at the command window prompt. ■ Never disable, delete, or otherwise interfere with the RPC service,

because doing so will cause severe problems, and access to the administration tools to repair the damage will be impossible.

■ Always make a copy of the system registry before making any

changes to services through the SC.

■ Delete service name will remove all calls to a service within the

Windows registry. The only way to recover the service after delet- ing it in this manner is through restoration of a registry backup.

Don’t do this to RPC.

■ To truly and completely remove a service, all of the file dependen-

cies of the service must be removed by manually deleting .dll files.

■ SC can be used to examine the services on another machine by

including the Universal Naming Convention (UNC) path as follows:

c:\sc \\servername [command] [service name]

There are only a few Windows services that are, under all condi- tions, “hands off.” This includes but is probably not limited to the following:

■ RPC

■ Windows Management Instrumentation ■ Workstation

Further hardening of Windows

Much can be said, some good, some bad, about the security of a Windows server, and if this is the chosen route, then further infor- mation than is within the scope of this book should be sought. Much has been written on file system protection, and the use of NTFS as a security tool, changing of passwords, bios security, and segmenting a network are subject matters worthy of an entire book. These are all aspects of hardening a Windows environment that should be studied in depth before administering such a network.

6.3.2

UNIX

Currently, UNIX OSs are undergoing a renaissance of sorts. With the explosion of users turning to Linux (an open-source version of UNIX created and driven by Linus Torvald) as a Windows alterna- tive, Unix has essentially gained a strong foothold in the OS market- place. With its open source and open community of developers, flaws are discovered and repaired quickly. Many of today’s appliance- based firewalls are Linux or UNIX based, prepackaged with firewall software, and hardened by firewall experts. Simply put, a UNIX firewall is to firewall deployment as fire hydrants are to dogs; it is the preferred method for disposal of unwanted network traffic byproducts. And this is the ultimate reason Linux and UNIX are better for security than Windows. There are many, many advanced and technical users who love to do nothing more than stress-test OSs. Frequently, these techs discover some flaw or vulnerability in an OS, and they may either report it to the manufacturer or use the flaw to start their own spam network. The temptation of having a network of many millions of computers at one’s disposal is, for some, too great to resist. With Linux, it is a matter of community status to be the one who discovered and possibly even created a fix

6.3 Selecting an operating system 121

for a particular vulnerability. As such, flaws and vulnerabilities in Linux tend to be repaired much more quickly, reducing the possibility of zero-hour attacks.

Navigating UNIX services

As with Windows, a UNIX machine can come with its own set of inherent flaws. By its nature, however, a UNIX box is less vulnera- ble to intrusion. This is by virtue of how services are started and managed and how privileges are assigned. In the case of a selection of Sun as the OS for firewall deployment, a hardened version of the software comes preinstalled. Likewise, there are several Linux deployments, such as eSoft, that offer similar services. Hardening a UNIX-based system involves a greater and more technical skill set than Windows (again, another vote for Windows). For the purposes here of showing and demonstrating service vulnerabilities of an OS slated for firewall deployment, Red Hat Linux will be the OS of reference.

On any Linux box, the list of services can be obtained from either the command shell or the graphical user interface (GUI). Both the etc/inetd.conf file and the etc/services file can be affected to disable services, but simply commenting out a line of the etc/services file does not truly harden the system. The preferred method is to remove the service package by typing

rpm –e packagename

at the command shell prompt.

SERVICES (LINUX)

Two particularly dangerous services with long histories of exploita- tion in Linux are Sendmail and the rsh/rlogin/rcp utilities, in partic- ular login, shell, and exec. The place to disable these is in etc/inetd.conf. They should be commented out (a number sign [#] comments out a line of code in a UNIX script) or removed com- pletely. Typing netstat –ta at the command line will list all the services offered by the machine. Services such as telnet, FTP, mail, and identd should be disabled; they have no place on a firewall server.

Enteringnetstat –an will list all active Internet services; that is, it will list all services that are actively listening at a particular port for traffic to enter the system. Once a service has been disabled by

commenting it out, inetd must be restarted or sent a hang-up (SIGHUP) signal to force the server to reread its configuration file.

Now,netstatis nice, and it will tell you if some process is listen- ing on a particular port, but it will not tell you the name of the pro- gram running the service. Entering lsof –I, however, will list the command, the process id (PID), user, packet type, and protocol of each listening service. This information is invaluable in determining the strength of a system to resist penetration.

Most Linux distributions come with what is known as a Transmission Control Protocol (TCP) Wrapper Daemon (tcpd). This wrapper acts as an intermediary between TCP requests (almost all legitimate Internet traffic falls within the TCP stack of protocols) and the actual port server. By invoking a wrapper around TCP services—which means that all requests for TCP services are handled first by the wrapper and, if the host is legitimate, then tcpd passes the request to the real server—great control can be exerted over how requests are handled or if they are handled at all. However, TCP wrappers only protect services executed from inetd. When relying on TCP wrappers, care must be taken to ensure that other services are not running. If external access to certain services is necessary, an /etc/hosts.allow file must be created and configured.

Configuring tcpd to allow internal access to services is as simple as adding the line: ALL:127to the /etc/hosts.allow file and ALL:ALL

to the /etc/hosts.deny file. TCP wrappers are the primary reason that Linux machines are considered by many to be easier to secure and, as a result, more secure than other more promiscuous OSs.

Services that are not run from the inetd usually originate in system boot. In these cases, each vendor is different, and to turn them off, research into the etc/rc.d1, d2, rc.d/d1, d2, or rc.d/rc1.d, rc2.d directories must be conducted. The numbers in these directo- ries refer to run levels and contain links to programs that are active in the respective run level. Determine run level by using the runlevel

command. To prevent a service from becoming active at system boot, remove it from the corresponding level into which the system boots at startup.

Many resources are available to help with the configuration (securing and hardening) of a Linux-based system. The previous descriptions merely provide a golden shovel for ground breaking. The real expertise comes from practice in implementation and in

6.3 Selecting an operating system 123

staying abreast of change in a very tumultuous environment (and career path).