unx44.htm

来自「Unix Unleashed, Third Edition is written」· HTM 代码 · 共 1,330 行 · 第 1/5 页

are covered in the section "Hardware Solutions" later in this chapter.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I9" NAME="I9">

<FONT SIZE=4><B>Security Policies</B>

<BR></FONT></A></CENTER></H3>

<P>If your computer or network of computers is used by someone other than you, then you need a security policy (also known as a proper use policy.) Your security policy is your chance to do a little social engineering of your own, and it educates your 
users, garners support from management, and sets standards of proper behavior for users and system administrators.

<BR></P>

<P>User education is important because security is often inconvenient and users are devious&#151;they will thwart your best-laid plans unless they understand the reasons for the inconvenience. Many users may feel that their account security is a personal 
matter, similar to the choice of whether to wear seat belts while driving. However, a multiuser computer system is a community of sorts, and one weak account is all a cracker needs to compromise an entire system.

<BR></P>

<P>Because security is inconvenient, you also need the support of management to enforce potentially unpopular security policies. Management will be more receptive to user inconvenience if you present evidence of the costs of a break-in, for instance an 
estimate of how much staff time it would take to restore your systems to a clean state after a break-in, or the cost to your company of theft of information.

<BR></P>

<P>Finally, a security policy tells users how you expect them to use the system, the consequences of misuse, and what actions you may take to investigate alleged misuse.

<BR></P>

<P>Not so long ago, a system administrator who suspected a user of the slightest wrongdoing would put on his shiny jackboots and stomp through users' files and electronic mailboxes like a hog rooting for truffles, looking for &quot;evidence.&quot; If he 
found any, the user got booted from the system. Then came the ECPA (Electronic Communications Privacy Act) of 1986, a federal law that provides criminal penalties for invading the privacy of users of computer systems and networks.

<BR></P>

<P>The ECPA legal waters are still murky because there hasn't yet been enough case law to clarify the intent of Congress. Since you probably don't want to be on the receiving end of such a clarification, you should act cautiously when gathering evidence. A 

security policy that clearly states what actions the systems administrator may take in investigating security incidents helps protect you from the possibly untoward consequences of &quot;just doing your job.&quot; However, this is not legal advice&#151;if 

you are concerned about how the ECPA may affect you, consult a lawyer, preferably one with expertise in computer law.

<BR></P>

<P>Before developing a security policy you should answer the following questions: What information and resources are you protecting? Who may want to break in? What are the likely consequences of a break-in?

<BR></P>

<P>If you don't know what you're protecting, you can't decide how strong your security profile should be. You have to have some idea of who the crackers may be because they come in all shapes and sizes. They vary from the kid in the basement with a 
Commodore 64, who wants to take your system for the computer equivalent of a joyride, to sophisticated industrial spies who may set up housekeeping on your system, covering their tracks by altering programs and log files. The consequences of a break-in 
depend on the value of the information and resources you're protecting, and the cost of recovery. Since a security policy usually imposes some inconveniences on your system's users and you want their cooperation in implementing it, you should tailor it to 

minimize inconvenience while maintaining the level of security your site needs.

<BR></P>

<P>A large collection of security policies is available for anonymous ftp from the host ftp.eff.org in the directory pub/CAF/policies. The USENET newsgroup comp.admin.policy is another good resource for getting feedback on a security policy.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I10" NAME="I10">

<FONT SIZE=4><B>User Authentication</B>

<BR></FONT></A></CENTER></H3>

<P>Authentication is a fancy name for identifying yourself as a valid user of a computer system, and it's your first defense against a break-in. Until recently, UNIX user authentication meant typing a valid login name and password. This is known as 
reusable password authentication, meaning that you enter the same password each time you log in. Reusable password authentication is too weak for some systems and will eventually be replaced by one-time password systems in which you enter a different 
password each login.

<BR></P>

<P>Reusable passwords are strong enough for some sites as long as users choose good passwords. Unfortunately, many don't&#151;research has shown that as many as 30%&#151;50% of passwords on typical UNIX systems can easily be guessed. Your security policy 
should both require strong passwords and provide guidelines for choosing them.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I11" NAME="I11">

<FONT SIZE=3><B>Picking Good Passwords</B>

<BR></FONT></A></CENTER></H4>

<P>Good passwords are 6&#151;8 characters long, use a rich character set (upper- and lowercase letters, digits, punctuation, and control characters), are not in English or foreign-language dictionaries, and don't contain any public information about you, 
such as your name or license number. Detailed guidelines for choosing passwords are presented in the security books mentioned in the section &quot;Finding More Information&quot; later in this chapter, but one good method is to take a random phrase and 
modify it in ingenious ways. For instance, the phrase &quot;If pigs had wings&quot; could yield the password &quot;1fpiGzhw.&quot; This password is a combination of a misspelled word (&quot;1f&quot; standing for &quot;if&quot;), a misspelled word with odd 

capitalization (&quot;pigZ&quot;), and the first letters of two more words. It's as secure as a reusable password can be since it isn't found in any dictionary and uses a fairly rich vocabulary (the digit &quot;1&quot; and capitalization), and it's easy to 

remember (but not to type).

<BR></P>

<P>Password choice is one of the areas in which users will deviously (and sometimes maliciously) thwart your security policies&#151;some people can't be convinced that they should pick a good password. You have two alternatives for these recalcitrant 
users: proactive and retroactive password vetting.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I12" NAME="I12">

<FONT SIZE=3><B>Password screening</B>

<BR></FONT></A></CENTER></H4>

<P>Retroactive password vetting puts you in the role of the cracker. You make your best effort to break your users' passwords, and if you succeed you notify the user and require her to change her password to something safer. The public domain program 
crack, written by Alec Muffett and available for anonymous ftp from ftp.cert.org and other sites, is one of the best. crack uses various tricks to permute login names and finger information into likely passwords and whatever word lists you specify. If 
you've got the disk space and CPU cycles you can feed crack the huge English and foreign-language word lists available for ftp from the host black.ox.ac.uk.

<BR></P>

<P>The problem with crack and similar programs is that users hate being told that you've cracked their passwords&#151;it's kind of like having a neighbor say, &quot;By the way, I was  rattling doorknobs last night and noticed that yours wasn't 
locked.&quot; However, crack is useful for gathering information you can use to make a case to management for stronger password security. For instance, if you can show that 30 percent of your users' passwords are easily guessed, you may be able to persuade 

your boss that proactive password screening is a good idea. And if you do plan to crack passwords, your users may react more positively if you make that clear in your security policy.

<BR></P>

<P>Proactive password screening is more like a preemptive strike&#151;if you prevent your users from choosing poor passwords, there's no reason to run crack. With proper education via your security policy users will react more positively (or at least less 

negatively) to being told they must choose a more secure password than to being told that you broke their current one. The passwd+ and npasswd programs screen passwords and can replace your standard passwd program. passwd+ is available for ftp from the 
host ftp.wustl.edu and others, and npasswd from ftp.luth.se.

<BR></P>

<P>If you have source code for your system's passwd program you can modify it to call the cracklib library of C functions. cracklib is also authored by Alec Muffett and makes checks similar to crack. A password that gets by cracklib's screening is not 
likely to be guessed, especially by crack. cracklib is available from ftp.cert.org and other hosts.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I13" NAME="I13">

<FONT SIZE=3><B>Password for System Accounts</B>

<BR></FONT></A></CENTER></H4>

<P>The system administrator must take special care in choosing a good password for her account and the superuser account. The superuser account must be protected because of the power it gives a cracker, and the system administrator's account because it can 

give access to the superuser account in many ways. For instance, if a system administrator's account is broken, the cracker can install a fake su program in his private bin directory that records the root password, removes itself, and then invokes the real 

su program. The system administrator account may have other special privileges that a cracker can make use of; for instance, membership in groups that allow you to read&#151;or worse, write&#151;system memory or raw disk devices, and permission to su to 
the superuser account. The systems administrator and root passwords should be changed often and should be as strong as you can make them.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I14" NAME="I14">

<FONT SIZE=3><B>Password Aging</B>

<BR></FONT></A></CENTER></H4>

<P>SVR4 UNIX also provides password aging facilities. Password aging places a time limit on the life of a password. The longer you keep the same password, the better the chance that someone will crack it, either by guessing it, watching you type it, or by 

cracking it offline on another computer. Changing passwords every 1&#151;6 months is sufficient for many sites, and password aging enforces that policy by requiring users to change their passwords when they expire. However, a poor implementation of 
password aging is worse than none at all. Users should be warned a few days in advance that their passwords will expire, because they may choose poor passwords if forced to choose on the spur of the moment.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I15" NAME="I15">

<FONT SIZE=3><B>Shadow Passwords</B>

<BR></FONT></A></CENTER></H4>

<P>SVR4 UNIX also provides shadow passwords. UNIX passwords are encrypted in the password file, but access to the encrypted version is valuable because it allows a cracker to crack them on her own computer. A fast personal computer can try thousands of 
guesses per second, which is a huge advantage for the cracker. Without access to the encrypted passwords, the cracker must try each of her guesses through the normal login procedure, which at best may take five to ten seconds per guess.

<BR></P>

<P>Shadow passwords hide the encrypted passwords in a file that is readable only by the superuser, thereby preventing crackers from cracking them offline. You should use them.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I16" NAME="I16">

<FONT SIZE=3><B>One-time Passwords</B>

<BR></FONT></A></CENTER></H4>

<P>Reusable passwords may be a serious problem if your users use your site to connect to remote sites on the Internet or if your local network is not physically secure. On February 3, 1994, the CERT/CC issued advisory CA-94:01. Crackers had broken into 
several major Internet sites, gained superuser access, and installed software to snoop the network and record the first packets of telnet, ftp, and rlogin sessions, which contain login names and passwords. According to the CERT/CC advisory, &quot;_all 
systems that offer remote access through rlogin, telnet, and FTP are at risk. Intruders have already captured access information for tens of thousands of systems across the Internet&quot; (emphasis added).

<BR></P>

<P>Internet programs such as telnet send unencrypted passwords over the network, making them vulnerable to snooping. The only way to truly solve this problem is to change the protocols so that user authentication doesn't require sending passwords over the 

network, but that won't happen soon.

<BR></P>

<P>Reusable passwords are valuable precisely because they're reusable. One-time passwords get around this problem by requiring a new password for each use&#151;the bad guys can sniff all they want, but it does them no good since the password that logs you 

in on Tuesday is different from the one you used Monday.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I17" NAME="I17">

<FONT SIZE=3><B>Smart Cards</B>

<BR></FONT></A></CENTER></H5>

<P>Smart cards are one way to implement one-time passwords. Users are issued credit card&#151;sized devices with numeric keypads and a PIN (personal identification number) that acts as the password for the card. When the user logs in to the computer it 
issues a challenge, which the user types into the smart card, along with her PIN. The smart card encrypts the challenge with other information such as the time, and displays a response, which the user types to the computer to log in. The computer generates 

a different challenge for each login. Each response is unique and can't be reused, so it doesn't matter if the challenge and response strings are sniffed. If the card is lost or stolen the login name and PIN are still required for the card to be used. 
Smart cards are a good solution to the reusable password problem, but they are too expensive for many sites.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I18" NAME="I18">

<FONT SIZE=3><B>S/Key</B>

<BR></FONT></A></CENTER></H5>

<P>S/Key is a solution for sites that can't afford smart cards. S/Key generates a sequential list of unique passwords and uses a different one for each login, but without using a smart card. Suppose that you log in to your computer from home over a phone 
line, or perhaps from a commercial Internet service provider. Your home computer runs an S/Key program that takes the place of a smart card by producing a response to the computer's challenge string, which is also generated by S/Key. If you're using a 
terminal that can't run  S/Key, or a computer that doesn't have S/Key installed, you can generate a list of passwords to be entered sequentially in future logins.

<BR></P>

<P>S/Key also provides a duress password that you enter to let the computer know that the bad guys have a gun to your head, and that although you want access now, you also want to invalidate the current password sequence. This is also useful if you lose 
your list of passwords and want to invalidate them until you can generate a new one.

<BR></P>

<P>The disadvantage of S/Key is that it may require you to carry around a list of valid passwords, which you could lose. However, as long as your login name doesn't appear on that list, a cracker still must guess that and the name of your computer. 
Further, since a list the size of a credit card can hold hundreds of passwords, and you only have to remember which one is next, the cracker still has to guess which of the passwords is next in the sequence. An advantage of S/Key is that it doesn't require 

a smart card. It's available for anonymous ftp from the hosts thumper.bellcore.com and crimelab.com.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I19" NAME="I19">

<FONT SIZE=3><B>Equivalent Hosts and </B><B><I>.rhosts</I></B><B> Authentication</B>

<BR></FONT></A></CENTER></H4>

<P>UNIX provides two mechanisms for authenticating yourself to other hosts on a network after you've logged in to one. Suppose that your organization has 10 workstations, named ws1, ws2,_ws10. Since the workstations are all administered by you, one should 

be as trustworthy as another. If you log in to ws3 you would like to get access to ws5 without providing a password, since you already gave one when you logged in to ws3. You can do this for your account alone with a .rhosts file, and for all the accounts 

on the computer (except the superuser account) with the file /etc/hosts.equiv.