15.3 Minimizing Risk by Minimizing Services

only for RuBoard - do not distribute or recompile

15.3 Minimizing Risk by Minimizing Services

An important way to minimize the threats to your web server is by minimizing the other services that are offered by the computer on which the web server is running. This technique works because each network service carries its own risks. By eliminating all nonessential services, you eliminate potential avenues through which an attacker could break into your system.

Making a Pre-Mac OS X Your Web Server

If security is your primary concern in running a web server, then you may wish to consider running your web server on a Macintosh computer running the OS 7, OS 8, or OS 9 operating systems. Because these versions of the Macintosh operating system were not delivered with a command-line interpreter, it is extremely difficult for attackers to break into the system and run programs of their own choosing. The Mac OS also doesn't come with dozens of network services enabled that can be compromised. And Apple has a very good history of providing carefully written, apparently bug-free code.

At least four web servers are available for the Macintosh:

• MacHTTP is a freely available web server that is easy to administer.

• WebStar, a commercial version of MacHTTP, is sold by StarNine Technologies, a subsidiary of Quarterdeck.

• WebStar Pro is an SSL-enabled version of WebStar, also sold by StarNine Technologies.

• Apple's personal web server is shipped with Mac OS 9 and possibly some releases of Mac OS 8.

Apple's Mac OS X operating system is based on FreeBSD. As such, its security is expected to be roughly similar to other Unix-based operating systems.

Table 15-1 lists some of the services that you should disable or restrict if you wish to run a secure server. Many of these services are widely considered "safe" today, but that doesn't mean that a serious flaw won't be discovered in one of these services sometime in the future. For example, in the spring of 2001 a vulnerability was found with the Berkeley Internet Name Daemon (BIND) that allowed anyone on the Internet to obtain superuser privileges on any Unix computer running the most common version of the software package. Sites that had nameservers running on their web servers were vulnerable. Sites that had turned off their nameservers were not.

If you don't need a service, disable it.

Table 15-1. Services to restrict on a secure server

Service to restrict	Reason
Domain Name Service (DNS)	Bugs in DNS implementations can be used to compromise your web server. Ideally, you should deploy computers that are only used for nameservice and nothing else. If you cannot run your own secure nameservers, you may wish to obtain nameservice from an upstream provider.
Mail (SMTP, POP, IMAP, etc.)	Bugs in sendmail and other mailers can be used to break into a computer system. Ideally, you should run mail services on computers other than your web server.
finger	finger can be used to learn information about a computer system that can then be used to launch other attacks. Bugs in the finger program can be used to compromise your site. finger was a very popular protocol in the 1980s and early 1990s, but its need today is questionable. Do not run finger in secure environments.
netstat, systat	snetstat and systat can reveal your system's configuration and usage patterns. Do not provide these services on secure machines.
chargen, echo	These services can be used to launch data-driven attacks and denial-of-service attacks. Disable them.
FTP	Do not run FTP if you can avoid it. The standard FTP sends usernames and passwords without encryption, opening up accounts accessed by FTP to attack. Although it is possible to use FTP with nonreusable password systems such as S/Key or SecureID, a better alternative is to use scp (Secure Copy, part of the ssh package) or WEB-DAV over SSL. If you must use FTP, use it only for updating the web server. If you need to run an anonymous FTP server, it should be run on a separate computer, and at the very least with a separate filesystem different from your web server.
Telnet	Do not allow interactive logins to your web server for anyone other than the site administrator (webmaster). If possible, use only a cryptographically enabled remote access systems, such as ssh or Kerberized Telnet. If you must Telnet without encryption, use a one-time password system, such as S/Key or SecureID.
Berkeley "r" commands (rlogin, rsh, rdist, etc.)	These commands use IP addresses for authentication that can be (and have been) spoofed. Use ssh and scp instead.

On a Unix server, you can easily restrict unneeded services by commenting out appropriate lines in inetd.conf. Another small handful of services that run as standalone daemons (portmapper is an example) can be eliminated in the "rc" files, found in the files /etc/rc and /etc/rc.local, and the subdirectories below /etc/rc.d and /usr/local/etc/rc.d. Many Unix servers now include support for the TCP wrappers file hosts.allow. By modifying this file, you can effectively control which hosts are allowed to access which services on your computer. You can also use IP filtering tools, such as ipfw, to provide host-based access control for outbound services.

Disabling IP services with an NT or Windows 2000 system is a little trickier, because settings are sprinkled throughout the registry, and some services have to be functioning for the sake of NT. Many NT services can be audited and disabled using the Services control panel.

The good news is that NT servers come with built-in access list capability. You can use this to prohibit all traffic to certain ports, and thereby achieve the same results as you would by shutting down services. (You can set IP filtering under the control panel's advanced TCP/IP settings.)

only for RuBoard - do not distribute or recompile