only for RuBoard - do not distribute or recompile |
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 ServerIf 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:
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.
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. |
|
only for RuBoard - do not distribute or recompile |