Table of Contents for
Practical UNIX and Internet Security, 3rd Edition

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Practical UNIX and Internet Security, 3rd Edition by Alan Schwartz Published by O'Reilly Media, Inc., 2003
  1. Cover
  2. Practical Unix & Internet Security, 3rd Edition
  3. A Note Regarding Supplemental Files
  4. Preface
  5. Unix “Security”?
  6. Scope of This Book
  7. Which Unix System?
  8. Conventions Used in This Book
  9. Comments and Questions
  10. Acknowledgments
  11. A Note to Would-Be Attackers
  12. I. Computer Security Basics
  13. 1. Introduction: Some Fundamental Questions
  14. What Is Computer Security?
  15. What Is an Operating System?
  16. What Is a Deployment Environment?
  17. Summary
  18. 2. Unix History and Lineage
  19. History of Unix
  20. Security and Unix
  21. Role of This Book
  22. Summary
  23. 3. Policies and Guidelines
  24. Planning Your Security Needs
  25. Risk Assessment
  26. Cost-Benefit Analysis and Best Practices
  27. Policy
  28. Compliance Audits
  29. Outsourcing Options
  30. The Problem with Security Through Obscurity
  31. Summary
  32. II. Security Building Blocks
  33. 4. Users, Passwords, and Authentication
  34. Logging in with Usernames and Passwords
  35. The Care and Feeding of Passwords
  36. How Unix Implements Passwords
  37. Network Account and Authorization Systems
  38. Pluggable Authentication Modules (PAM)
  39. Summary
  40. 5. Users, Groups, and the Superuser
  41. Users and Groups
  42. The Superuser (root)
  43. The su Command: Changing Who You Claim to Be
  44. Restrictions on the Superuser
  45. Summary
  46. 6. Filesystems and Security
  47. Understanding Filesystems
  48. File Attributes and Permissions
  49. chmod: Changing a File’s Permissions
  50. The umask
  51. SUID and SGID
  52. Device Files
  53. Changing a File’s Owner or Group
  54. Summary
  55. 7. Cryptography Basics
  56. Understanding Cryptography
  57. Symmetric Key Algorithms
  58. Public Key Algorithms
  59. Message Digest Functions
  60. Summary
  61. 8. Physical Security for Servers
  62. Planning for the Forgotten Threats
  63. Protecting Computer Hardware
  64. Preventing Theft
  65. Protecting Your Data
  66. Story: A Failed Site Inspection
  67. Summary
  68. 9. Personnel Security
  69. Background Checks
  70. On the Job
  71. Departure
  72. Other People
  73. Summary
  74. III. Network and Internet Security
  75. 10. Modems and Dialup Security
  76. Modems: Theory of Operation
  77. Modems and Security
  78. Modems and Unix
  79. Additional Security for Modems
  80. Summary
  81. 11. TCP/IP Networks
  82. Networking
  83. IP: The Internet Protocol
  84. IP Security
  85. Summary
  86. 12. Securing TCP and UDP Services
  87. Understanding Unix Internet Servers and Services
  88. Controlling Access to Servers
  89. Primary Unix Network Services
  90. Managing Services Securely
  91. Putting It All Together: An Example
  92. Summary
  93. 13. Sun RPC
  94. Remote Procedure Call (RPC)
  95. Secure RPC (AUTH_DES)
  96. Summary
  97. 14. Network-Based Authentication Systems
  98. Sun’s Network Information Service (NIS)
  99. Sun’s NIS+
  100. Kerberos
  101. LDAP
  102. Other Network Authentication Systems
  103. Summary
  104. 15. Network Filesystems
  105. Understanding NFS
  106. Server-Side NFS Security
  107. Client-Side NFS Security
  108. Improving NFS Security
  109. Some Last Comments on NFS
  110. Understanding SMB
  111. Summary
  112. 16. Secure Programming Techniques
  113. One Bug Can Ruin Your Whole Day . . .
  114. Tips on Avoiding Security-Related Bugs
  115. Tips on Writing Network Programs
  116. Tips on Writing SUID/SGID Programs
  117. Using chroot( )
  118. Tips on Using Passwords
  119. Tips on Generating Random Numbers
  120. Summary
  121. IV. Secure Operations
  122. 17. Keeping Up to Date
  123. Software Management Systems
  124. Updating System Software
  125. Summary
  126. 18. Backups
  127. Why Make Backups?
  128. Backing Up System Files
  129. Software for Backups
  130. Summary
  131. 19. Defending Accounts
  132. Dangerous Accounts
  133. Monitoring File Format
  134. Restricting Logins
  135. Managing Dormant Accounts
  136. Protecting the root Account
  137. One-Time Passwords
  138. Administrative Techniques for Conventional Passwords
  139. Intrusion Detection Systems
  140. Summary
  141. 20. Integrity Management
  142. The Need for Integrity
  143. Protecting Integrity
  144. Detecting Changes After the Fact
  145. Integrity-Checking Tools
  146. Summary
  147. 21. Auditing, Logging, and Forensics
  148. Unix Log File Utilities
  149. Process Accounting: The acct/pacct File
  150. Program-Specific Log Files
  151. Designing a Site-Wide Log Policy
  152. Handwritten Logs
  153. Managing Log Files
  154. Unix Forensics
  155. Summary
  156. V. Handling Security Incidents
  157. 22. Discovering a Break-in
  158. Prelude
  159. Discovering an Intruder
  160. Cleaning Up After the Intruder
  161. Case Studies
  162. Summary
  163. 23. Protecting Against Programmed Threats
  164. Programmed Threats: Definitions
  165. Damage
  166. Authors
  167. Entry
  168. Protecting Yourself
  169. Preventing Attacks
  170. Summary
  171. 24. Denial of Service Attacks and Solutions
  172. Types of Attacks
  173. Destructive Attacks
  174. Overload Attacks
  175. Network Denial of Service Attacks
  176. Summary
  177. 25. Computer Crime
  178. Your Legal Options After a Break-in
  179. Criminal Hazards
  180. Criminal Subject Matter
  181. Summary
  182. 26. Who Do You Trust?
  183. Can You Trust Your Computer?
  184. Can You Trust Your Suppliers?
  185. Can You Trust People?
  186. Summary
  187. VI. Appendixes
  188. A. Unix Security Checklist
  189. Preface
  190. Chapter 1: Introduction: Some Fundamental Questions
  191. Chapter 2: Unix History and Lineage
  192. Chapter 3: Policies and Guidelines
  193. Chapter 4: Users, Passwords, and Authentication
  194. Chapter 5: Users, Groups, and the Superuser
  195. Chapter 6: Filesystems and Security
  196. Chapter 7: Cryptography Basics
  197. Chapter 8: Physical Security for Servers
  198. Chapter 9: Personnel Security
  199. Chapter 10: Modems and Dialup Security
  200. Chapter 11: TCP/IP Networks
  201. Chapter 12: Securing TCP and UDP Services
  202. Chapter 13: Sun RPC
  203. Chapter 14: Network-Based Authentication Systems
  204. Chapter 15: Network Filesystems
  205. Chapter 16: Secure Programming Techniques
  206. Chapter 17: Keeping Up to Date
  207. Chapter 18: Backups
  208. Chapter 19: Defending Accounts
  209. Chapter 20: Integrity Management
  210. Chapter 21: Auditing, Logging, and Forensics
  211. Chapter 22: Discovering a Break-In
  212. Chapter 23: Protecting Against Programmed Threats
  213. Chapter 24: Denial of Service Attacks and Solutions
  214. Chapter 25: Computer Crime
  215. Chapter 26: Who Do You Trust?
  216. Appendix A: Unix Security Checklist
  217. Appendix B: Unix Processes
  218. Appendixes C, D, and E: Paper Sources, Electronic Sources, and Organizations
  219. B. Unix Processes
  220. About Processes
  221. Signals
  222. Controlling and Examining Processes
  223. Starting Up Unix and Logging In
  224. C. Paper Sources
  225. Unix Security References
  226. Other Computer References
  227. D. Electronic Resources
  228. Mailing Lists
  229. Web Sites
  230. Usenet Groups
  231. Software Resources
  232. E. Organizations
  233. Professional Organizations
  234. U.S. Government Organizations
  235. Emergency Response Organizations
  236. Index
  237. Index
  238. Index
  239. Index
  240. Index
  241. Index
  242. Index
  243. Index
  244. Index
  245. Index
  246. Index
  247. Index
  248. Index
  249. Index
  250. Index
  251. Index
  252. Index
  253. Index
  254. Index
  255. Index
  256. Index
  257. Index
  258. Index
  259. Index
  260. Index
  261. Index
  262. Index
  263. About the Authors
  264. Colophon
  265. Copyright

Logging in with Usernames and Passwords

Every person who uses a Unix computer should have her own account. An account is identified by a user ID number (UID) that is associated with one or more usernames (also known as account names ). Traditionally, each account also has a secret password associated with it to prevent unauthorized use. You need to know both your username and your password to log into a Unix system.

Unix Usernames

The username is an identifier: it tells the computer who you are. In contrast, a password is an authenticator: you use it to prove to the operating system that you are who you claim to be. A single person can have more than one Unix account on the same computer. In this case, each account would have its own username.

Standard Unix usernames may be between one and eight characters long, although many Unix systems today allow usernames that are longer. Within a single Unix computer, usernames must be unique: no two users can have the same one. (If two people did have the same username on a single system, then they would really be sharing the same account.) Traditionally, Unix passwords were also between one and eight characters long, although most Unix systems now allow longer passwords as well. Longer passwords are generally more secure because they are harder to guess. More than one user can theoretically have the same password, although if they do, that usually indicates that both users have picked a bad password.

A username can be any sequence of characters you want (with some exceptions), and does not necessarily correspond to a real person’s name.

Tip

Some versions of Unix have problems with usernames that do not start with a lowercase letter or that contain special characters such as punctuation or control characters. Usernames containing certain unusual characters will also cause problems for various application programs, including some network mail programs. For this reason, many sites allow only usernames that contain lowercase letters and numbers and further require that all usernames start with a letter.

Your username identifies you to Unix in the same way that your first name identifies you to your friends. When you log into the Unix system, you tell it your username in the same way that you might say, “Hello, this is Sabrina,” when you pick up the telephone.[31] Most systems use the same identifier for both usernames and email addresses. For this reason, organizations that have more than one computer often require people to use the same username on every machine to minimize confusion.

There is considerable flexibility in choosing a username. For example, John Q. Random might have any of the following usernames; they are all potentially valid:

john
johnqr
johnr
jqr
jqrandom
jrandom
random
randomjq

Alternatively, John might have a username that appears totally unrelated to his real name, like avocado or t42. Having a username similar to your own name is merely a matter of convenience.

Tip

In some cases, having an unrelated name may be a desired feature because it either masks your identity in email and online chat rooms, or projects an image different from your usual one: tall62, fungirl, anonymus, svelte19, and richguy. Of course, as we noted in the last chapter, “handles” that don’t match one’s real name can also be used to hide the true identity of someone doing something unethical or illegal. Be cautious about drawing conclusions about someone based on the email name or account name that they present.

Most organizations require that usernames be at least three characters long. Single-character usernames are simply too confusing for most people to deal with, no matter how easy you might think it would be to be user i or x. Usernames that are two characters long are also confusing for some people, because they usually don’t provide enough information to match a name in memory: who was zt@ex.com, anyway? In general, names with little intrinsic meaning, such as t42xp96wl, can also cause confusion because they are more difficult for correspondents to remember.

Some organizations assign usernames using standardized rules, such as the first initial of a person’s first name and then the first six letters of their last name, optionally followed by a number. Other organizations let users pick their own names. Some organizations and online services assign an apparently random string of characters as the usernames; although this is generally not popular, it can improve security—especially if these usernames are not used for electronic mail. Although some randomly generated strings can be hard to remember, there are several algorithms that generate easy-to-remember random strings by using a small number of mnemonic rules; typical usernames generated by these systems are xxp44 and acactt. If you design a system that gives users randomly generated usernames, it is a good idea to let people reject a username and ask for another, lest somebody gets stuck with a hard-to-remember username like xp9uu6wi.

Unix also has special accounts that are used for administrative purposes and special system functions. These accounts are not normally used by individual users.

Authenticating Users

After you tell Unix who you are, you must prove your identity to a certain degree of confidence (trust). This process is called authentication. Classically, there are three different ways that you can authenticate yourself to a computer system, and you use one or more of them each time:

  1. You can tell the computer something that you know (for example, a password).

  2. You can present the computer with something you have (for example, a card key).

  3. You can let the computer measure something about you (for example, your fingerprint).

None of these systems is foolproof. For example, by eavesdropping on your terminal line, somebody can learn your password. By attacking you at gunpoint, somebody can steal your card key. And if your attacker has a knife, you might even lose your finger! In general, the more trustworthy the form of authentication, the more aggressive an attacker must be to compromise it. In the past, the most trustworthy authentication techniques have also been the most difficult to use, although this is slowly changing.

Authenticating with Passwords

Passwords are the simplest form of authentication: they are a secret that you share with the computer. When you log in, you type your password to prove to the computer that you are who you claim to be. The computer ensures that the password you type matches the account that you have specified. If it matches, you are allowed to proceed.

Unix does not display your password as you type it. This gives you extra protection if the transcript of your session is being logged or if somebody is watching over your shoulder as you type—a technique that is sometimes referred to as shoulder surfing .

Conventional passwords have been part of Unix since its early years. The advantage of this system is that it runs without any special equipment, such as smartcard readers or fingerprint scanners.

The disadvantage of conventional passwords is that they are easily captured and reused—especially in a network-based environment. Although passwords can be used securely and effectively, doing so requires constant vigilance to make sure that an unencrypted password is not inadvertently sent over the network, allowing it to be captured with a password sniffer. Passwords can also be stolen if they are typed on a computer that has been compromised with a keystroke recorder. Today, even unsophisticated attackers can use such tools to capture passwords. Indeed, the only way to safely use a Unix computer remotely over a network such as the Internet is to use one-time passwords, encryption, or both (see Section 4.3.3 later in this chapter and also see Chapter 7).[32]

Unfortunately, we live in an imperfect world, and most Unix systems continue to depend upon reusable passwords for user authentication. Be careful!

Entering your password

When you log in, you tell the computer who you are by typing your username at the login prompt (the identification step). You then type your password (in response to the password prompt) to authenticate that you are who you claim to be. For example:

login: rachel
password: luV2-fred

Unix does not display your password when you type it.

If the password that you supply with your username corresponds to the password that is on file for the provided username, Unix logs you in and gives you full access to the user’s files, commands, and devices. If the username and the password do not match, Unix does not log you in.

On some versions of Unix, if somebody tries to log into an account and supplies an invalid password several times in succession, that account will become locked. A locked account can be unlocked only by the system administrator. Locking has three functions:

  1. It protects the system from attackers who persist in trying to guess a password; before they can guess the correct password, the account is shut down.

  2. It lets you know that someone has been trying to break into your account.

  3. It lets your system administrator know that someone has been trying to break into the computer.

If you find yourself locked out of your account, you should contact your system administrator and get your password changed to something new. Don’t change your password back to what it was before you were locked out.

The automatic lockout feature can prevent unauthorized use, but it can also be used to conduct denial of service attacks, or by an attacker to lock selected users out of the system so as to prevent discovery of his actions. A practical joker can use it to annoy fellow employees or students. And you can accidentally lock yourself out if you try to log in too many times before you’ve had your morning coffee.

In our experience, the disadvantages of indefinite automatic lockouts outweigh the benefits. A much better method is to employ an increasing delay mechanism in the login. After a fixed number of unsuccessful logins, an increasing delay can be inserted between each successive prompt. Implementing such delays in a network environment requires maintaining a record of failed login attempts, so that the delay cannot be circumvented by an attacker who merely disconnects from the target machine and reconnects.

Changing your password

You can change your password with the Unix passwd command. You will first be asked to type your old password, then a new one. By asking you to type your old password first, passwd prevents somebody from walking up to a terminal that you left yourself logged into and then changing your password without your knowledge.

Unix makes you type the new password twice:

% passwd
Changing password for sarah.
Old password:tuna4fis
 
New password: nosSMi32
 
Retype new password: nosSMi32

%

If the two passwords you type don’t match, your password remains unchanged. This is a safety precaution: if you made a mistake typing the new password and Unix only asked you once, then your password could be changed to some new value and you would have no way of knowing that value.

Note

On systems that use Sun Microsystems NIS or NIS+, you may need to use the command yppasswd or nispasswd to change your password. Except for having different names, these programs work in the same way as passwd. However, when they run, they update your password in the network database with NIS or NIS+. When this happens, your password will be immediately available on other clients on the network. With NIS, your password will be distributed during the next regular update.

The -r option to the passwd command can also be used under Solaris. To change NIS or NIS+ passwords, the format would be passwd -r nis or passwd -r nisplus, respectively. It is possible to have a local machine password that is different from the one in the network database, and that would be changed with passwd -r files.

Even though passwords are not echoed when they are printed, the Backspace or Delete key (or whatever key you have bound to the “erase” function) will still delete the last character typed, so if you make a mistake, you can correct it.

Once you have changed your password, your old password will no longer work. Do not forget your new password! If you forget your new password, you will need to have the system administrator set it to something you can use to log in and try again.[33]

If your system administrator gives you a new password, immediately change it to something else that only you know! Otherwise, if your system administrator is in the habit of setting the same password for forgetful users, your account may be compromised by someone else who has had a temporary lapse of memory; see Password: ChangeMe for an example.

Warning

If you are a system manager and you need to change a user’s password, do not change the user’s password to something like changeme or password, and then rely on the user to change their password to something else. Many users will not take the time to change their passwords but will, instead, continue to use the password that you have inadvertently “assigned” to them. Give the user a good password, and give that user a different password from every other user whose password you have reset.

Verifying your new password

After you have changed your password, try logging into your account with the new password to make sure that you’ve entered the new password properly. Ideally, you should do this without logging out, so you will have some recourse if you did not change your password properly. This is especially crucial if you are logged in as root and you have just changed the root password!

One way to try out your new password is to use the su command. Normally, the su command is used to switch to another account. But as the command requires that you type the password of the account to which you are switching, you can effectively use the su command to test the password of your own account.

% /bin/su nosmis
password: mypassword

%

(Of course, instead of typing nosmis and mypassword , use your own account name and password.)

If you’re using a machine that is on a network, you can use the telnet, rlogin, or ssh programs to loop back through the network to log in a second time by typing:

% ssh -l dawn 
                     localhost

dawn@loaclhost's password: w3kfsc!

Last login: Sun Feb 3 11:48:45 on ttyb
%

You can replace localhost in the above example with the name of your computer. This method is also useful when testing a change in the root password, as the su command does not prompt for a password when run by root.

If you try one of the earlier methods and discover that your password is not what you thought it was, you have a definite problem. To change the password to something you do know, you will need the current password. However, you don’t know that password! You will need the help of the system administrator to fix the situation. (That’s why you shouldn’t log out—if the time is 2:00 a.m. on Saturday, you might not be able to reach the administrator until Monday morning, and you might want to get some work done before then.)

The superuser (user root) can’t decode the password of any user. However, the system administrator can help you when you don’t know what you’ve set your password to by using the superuser account to set your password to something known.

Warning

If you get email from your system manager advising you that there are system problems and that you should immediately change your password to tunafish (or some other value), disregard the message and report it to your system management. These kinds of email messages are frequently sent by computer criminals to novice users. The hope is that the novice user will comply with the request and change his password to the one that is suggested—often with devastating results.

Changing another user’s password

If you are running as the superuser (or the network administrator, in the case of NIS+), you can set the password of any user, including yourself, without supplying the old password. You do this by supplying the username to the passwd command when you invoke it:

# passwd cindy
New password: NewR-pas

Retype new password: NewR-pas

#


[31] Even if you aren’t Sabrina, saying that you are Sabrina identifies you as Sabrina. Of course, if you are not Sabrina, your voice will probably not authenticate you as Sabrina, provided that the person you are speaking with knows what Sabrina actually sounds like.

[32] Well-chosen passwords are still quite effective for most standalone systems with hardwired terminals, and when used in cryptographic protocols with mechanisms to prevent replay attacks.

[33] And if you are the system administrator, you’ll have to log in as the superuser to change your password. If you’ve forgotten the superuser password, you may need to take drastic measures to recover.

[34] The control characters ^@, ^C, ^G, ^H, ^J, ^M, ^Q, ^S, and ^[ should not be put in passwords, because they can be interpreted by the system. If your users will log in using xdm, users should avoid all control characters, as xdm often filters them out. You should also beware of control characters that may interact with your terminal programs, terminal concentrator monitors, and other intermediate systems you may use; for instance, the ~ character is often used as an escape character in ssh and rsh sessions. Finally, you may wish to avoid the # and @ characters, as some Unix systems still interpret these characters with their ancient use as erase and kill characters.