Linux Network Administrator's Guide翻译1.4
时间：2007-02-12 来源：gadfly0217
1.4. Maintaining Your System
Throughout this book, we will mainly deal with installation and configuration issues. Administration is, however, much more than thatafter setting up a service, you have to keep it running, too. For most services, only a little attendance will be necessary, while some, such as mail, require that you perform routine tasks to keep your system up to date. We will discuss these tasks in later chapters. The absolute minimum in maintenance is to check system and per-application logfiles regularly for error conditions and unusual events. Often, you will want to do this by writing a couple of administrative shell scripts and periodically running them from cron(一种守护进程). The source distributions of some major applications contain such scripts. You only have to tailor them to suit your needs and preferences. The output from any of your cron jobs should be mailed to an administrative account. By default, many applications will send error reports, usage statistics, or logfile summaries to the root account. This makes sense only if you log in as root frequently; a much better idea is to forward root's mail to your personal account by setting up a mail alias(联名) as described in Chapters Chapter 11 and Chapter 12. However carefully you have configured your site, Murphy's Law guarantees that some problem will surface eventually. Therefore, maintaining a system also means being available for complaints. Usually, people expect that the system administrator can at least be reached via email as root, but there are also other addresses that are commonly used to reach the person responsible for a specific aspect of maintenence. For instance, complaints about a malfunctioning mail configuration will usually be addressed to postmaster, and problems with the news system may be reported to newsmaster or usenet. Mail to hostmaster should be redirected to the person in charge of the host's basic network services, and the DNS name service if you run a nameserver. 1.4.1. System Security
Another very important aspect of system administration in a network environment is protecting your system and users from intruders(入侵者). Carelessly managed systems offer malicious people many targets. Attacks range from password guessing to Ethernet snooping(窥听), and the damage caused may range from faked mail messages to data loss or violation of your users' privacy. We will mention some particular problems when discussing the context in which they may occur and some common defenses against them. This section will discuss a few examples and basic techniques for dealing with system security. Of course, the topics covered cannot treat all security issues in detail; they merely serve to illustrate the problems that may arise. Therefore, reading a good book on security is an absolute must, especially in a networked system. System security starts with good system administration. This includes checking the ownership and permissions of all vital files and directories and monitoring use of privileged accounts. The COPS program, for instance, will check your filesystem and common configuration files for unusual permissions or other anomalies. Another tool, Bastille Linux, developed by Jay Beale and found at http://www.bastille-linux.org, contains a number of scripts and programs that can be used to lock down a Linux system. It is also wise to use a password suite that enforces certain rules on the users' passwords that make them hard to guess. The shadow password suite, now a default, requires a password to have at least five letters and to contain both upper- and lowercase numbers, as well as nonalphabetic characters. When making a service accessible to the network, make sure to give it "least privilege"(最小权限); don't permit it to do things that aren't required for it to work as designed. For example, you should make programs setuid to root or some other privileged account only when necessary. Also, if you want to use a service for only a very limited application, don't hesitate to configure it as restrictively as your special application allows. For instance, if you want to allow diskless hosts to boot from your machine, you must provide Trivial File Transfer Protocol (TFTP) so that they can download basic configuration files from the /boot directory. However, when used unrestrictively, TFTP allows users anywhere in the world to download any world-readable file from your system. If this is not what you want, restrict TFTP service to the /boot directory (we'll come back to this in Chapter 10). You might also want to restrict certain services to users from certain hosts, say from your local network. In Chapter 10, we introduce tcpd, which does this for a variety of network applications. More sophisticated methods of restricting access to particular hosts or services will be explored in Chapter 7. Another important point is to avoid "dangerous" software. Of course, any software you use can be dangerous because software may have bugs that clever people might exploit to gain access to your system. Things like this happen, and there's no complete protection against it. This problem affects free software and commercial products alike.[5] However, programs that require special privilege are inherently more dangerous than others because any loophole can have drastic consequences.[6] If you install a setuid program for network purposes, be doubly careful to check the documentation so that you don't create a security breach by accident. Another source of concern should be programs that enable login or command execution with limited authentication. The rlogin, rsh, and rexec commands are all very useful, but offer very limited authentication of the calling party. Authentication is based on trust of the calling hostname obtained from a nameserver (we'll talk about these later), which can be faked. Today it should be standard practice to disable the r commands completely and replace them with the ssh suite of tools. The ssh tools use a much more reliable authentication method and provide other services, such as encryption and compression, as well. You can never rule out the possibility that your precautions might fail, regardless of how careful you have been. You should therefore make sure that you detect intruders early. Checking the system logfiles is a good starting point, but the intruder is probably clever enough to anticipate this action and will delete any obvious traces he or she left. However, there are tools like tripwire, written by Gene Kim and Gene Spafford, that allow you to check vital system files to see if their contents or permissions have been changed. tripwire computes various strong checksums over these files and stores them in a database. During subsequent runs, the checksums are recomputed and compared to the stored ones to detect any modifications. Finally, it's always important to be proactive about security. Monitoring the mailing lists for updates and fixes to the applications that you use is critical in keeping current with new releases. Failing to update something such as Apache or OpenSSL can lead directly to system compromise. One fairly recent example of this was found with the Linux Slapper worm, which propagated using an OpenSSL vulnerability. While keeping up to date can seem a daunting and time-consuming effort, administrators who were quick to react and upgrade their OpenSSL implementations ended up saving a great deal of time because they did not have to restore compromised systems!
Throughout this book, we will mainly deal with installation and configuration issues. Administration is, however, much more than thatafter setting up a service, you have to keep it running, too. For most services, only a little attendance will be necessary, while some, such as mail, require that you perform routine tasks to keep your system up to date. We will discuss these tasks in later chapters. The absolute minimum in maintenance is to check system and per-application logfiles regularly for error conditions and unusual events. Often, you will want to do this by writing a couple of administrative shell scripts and periodically running them from cron(一种守护进程). The source distributions of some major applications contain such scripts. You only have to tailor them to suit your needs and preferences. The output from any of your cron jobs should be mailed to an administrative account. By default, many applications will send error reports, usage statistics, or logfile summaries to the root account. This makes sense only if you log in as root frequently; a much better idea is to forward root's mail to your personal account by setting up a mail alias(联名) as described in Chapters Chapter 11 and Chapter 12. However carefully you have configured your site, Murphy's Law guarantees that some problem will surface eventually. Therefore, maintaining a system also means being available for complaints. Usually, people expect that the system administrator can at least be reached via email as root, but there are also other addresses that are commonly used to reach the person responsible for a specific aspect of maintenence. For instance, complaints about a malfunctioning mail configuration will usually be addressed to postmaster, and problems with the news system may be reported to newsmaster or usenet. Mail to hostmaster should be redirected to the person in charge of the host's basic network services, and the DNS name service if you run a nameserver. 1.4.1. System Security
Another very important aspect of system administration in a network environment is protecting your system and users from intruders(入侵者). Carelessly managed systems offer malicious people many targets. Attacks range from password guessing to Ethernet snooping(窥听), and the damage caused may range from faked mail messages to data loss or violation of your users' privacy. We will mention some particular problems when discussing the context in which they may occur and some common defenses against them. This section will discuss a few examples and basic techniques for dealing with system security. Of course, the topics covered cannot treat all security issues in detail; they merely serve to illustrate the problems that may arise. Therefore, reading a good book on security is an absolute must, especially in a networked system. System security starts with good system administration. This includes checking the ownership and permissions of all vital files and directories and monitoring use of privileged accounts. The COPS program, for instance, will check your filesystem and common configuration files for unusual permissions or other anomalies. Another tool, Bastille Linux, developed by Jay Beale and found at http://www.bastille-linux.org, contains a number of scripts and programs that can be used to lock down a Linux system. It is also wise to use a password suite that enforces certain rules on the users' passwords that make them hard to guess. The shadow password suite, now a default, requires a password to have at least five letters and to contain both upper- and lowercase numbers, as well as nonalphabetic characters. When making a service accessible to the network, make sure to give it "least privilege"(最小权限); don't permit it to do things that aren't required for it to work as designed. For example, you should make programs setuid to root or some other privileged account only when necessary. Also, if you want to use a service for only a very limited application, don't hesitate to configure it as restrictively as your special application allows. For instance, if you want to allow diskless hosts to boot from your machine, you must provide Trivial File Transfer Protocol (TFTP) so that they can download basic configuration files from the /boot directory. However, when used unrestrictively, TFTP allows users anywhere in the world to download any world-readable file from your system. If this is not what you want, restrict TFTP service to the /boot directory (we'll come back to this in Chapter 10). You might also want to restrict certain services to users from certain hosts, say from your local network. In Chapter 10, we introduce tcpd, which does this for a variety of network applications. More sophisticated methods of restricting access to particular hosts or services will be explored in Chapter 7. Another important point is to avoid "dangerous" software. Of course, any software you use can be dangerous because software may have bugs that clever people might exploit to gain access to your system. Things like this happen, and there's no complete protection against it. This problem affects free software and commercial products alike.[5] However, programs that require special privilege are inherently more dangerous than others because any loophole can have drastic consequences.[6] If you install a setuid program for network purposes, be doubly careful to check the documentation so that you don't create a security breach by accident. Another source of concern should be programs that enable login or command execution with limited authentication. The rlogin, rsh, and rexec commands are all very useful, but offer very limited authentication of the calling party. Authentication is based on trust of the calling hostname obtained from a nameserver (we'll talk about these later), which can be faked. Today it should be standard practice to disable the r commands completely and replace them with the ssh suite of tools. The ssh tools use a much more reliable authentication method and provide other services, such as encryption and compression, as well. You can never rule out the possibility that your precautions might fail, regardless of how careful you have been. You should therefore make sure that you detect intruders early. Checking the system logfiles is a good starting point, but the intruder is probably clever enough to anticipate this action and will delete any obvious traces he or she left. However, there are tools like tripwire, written by Gene Kim and Gene Spafford, that allow you to check vital system files to see if their contents or permissions have been changed. tripwire computes various strong checksums over these files and stores them in a database. During subsequent runs, the checksums are recomputed and compared to the stored ones to detect any modifications. Finally, it's always important to be proactive about security. Monitoring the mailing lists for updates and fixes to the applications that you use is critical in keeping current with new releases. Failing to update something such as Apache or OpenSSL can lead directly to system compromise. One fairly recent example of this was found with the Linux Slapper worm, which propagated using an OpenSSL vulnerability. While keeping up to date can seem a daunting and time-consuming effort, administrators who were quick to react and upgrade their OpenSSL implementations ended up saving a great deal of time because they did not have to restore compromised systems!
相关阅读 更多 +
