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

Understanding Cryptography

Cryptography is a collection of mathematical techniques for protecting information. Using cryptography, you can transform written words and other kinds of messages so that they are unintelligible to anyone who does not possess a specific mathematical key necessary to unlock the message. The process of using cryptography to scramble a message is called encryption . The process of unscrambling the message by use of the appropriate key is called decryption . Figure 7-1 illustrates how these two processes fit together.

Encryption and decryption

Figure 7-1. Encryption and decryption

Cryptography is used to prevent information from being accessed by an unauthorized recipient. In theory, once a piece of information is encrypted, the encrypted data can be accidentally disclosed or intercepted by a third party without compromising the security of the information, provided that the key necessary to decrypt the information is not disclosed and that the method of encryption will resist attempts to decrypt the message without the key.

For example, here is a message that you might want to encrypt:

SSL is a cryptographic protocol

And here is how the message might look after it has been encrypted:

Ç'@%[»FÇ«;$TfiP∑|x¿EûóõÑ%ß+ö~·...aÜ"BÆuâw

Because the decryption key is not shown, it should not be practical to take the preceding line of gibberish and turn it back into the original message.

Roots of Cryptography

The science of cryptography is thousands of years old. In his book The Code Breakers, David Kahn traces the roots of cryptography back to ancient Egypt, Greece, and Rome. For example, writes Kahn, Greek generals used cryptography to send coded messages to commanders who were in the field. In the event that a messenger was intercepted by the enemy, the message’s content would not be revealed.

Most cryptographic systems have been based on two techniques: substitution and transposition:

Substitution

Substitution is based on the principle of replacing each letter in the message you wish to encrypt with another one. The Caesar cipher, for example, substitutes the letter “a” with the letter “d,” the letter “b” with the letter “e,” and so on. Some substitution ciphers use the same substitution scheme for every letter in the message that is being encrypted; others use different schemes for different letters.

Transposition

Transposition is based on scrambling the characters that are in the message. One transposition system involves writing a message into a table row by row, then reading it out column by column. Double transposition ciphers involve using two such transformations.

In the early part of the 20th century, a variety of electromechanical devices were built in Europe and the United States for the purpose of encrypting messages sent by telegraph or radio. These systems relied principally on substitution because there was no way to store multiple characters necessary to use transposition techniques. Today, encryption algorithms running on high-speed digital computers use substitution and transposition in combination, as well as other mathematical functions.

Cryptography as a Dual-Use Technology

Cryptography is a “dual-use” technology—that is, cryptography has both military and civilian applications. There are many other examples of dual-use technologies, including carbon fibers, high-speed computers, and even trucks. Historically, cryptography has long been seen as a military technology.[78] Nearly all of the historical examples of cryptography, from Greece and Rome into the modern age, are stories of armies, spies, and diplomats who used cryptography to shield messages transmitted across great distances. There was Julius Caesar, who used a simple substitution cipher to scramble messages sent back from Gaul. Mary, Queen of Scots, tried to use cryptography to protect the messages that she sent to her henchmen who were planning to overthrow the British Crown. And, of course, Hitler used the Enigma encryption cipher to scramble messages sent by radio to the German armies and U-Boats during World War II.

There is also a tradition of nonmilitary use of cryptography that is many centuries old. There are records of people using cryptography to protect religious secrets, to hide secrets of science and industry, and to arrange clandestine romantic trysts. In Victorian England, lovers routinely communicated by printed encrypted advertisements in the London newspapers. Lovers again relied on encryption during World War I when mail sent between the U.S. and foreign countries was routinely opened by Postal Service inspectors looking for communiqués between spies. These encrypted letters, when they were intercepted, were sent to Herbert Yardley’s offices in New York City, which made a point of decrypting each message before it was resealed and sent along its way. As Herbert Yardley wrote in his book The American Black Chamber, lovers accounted for many more encrypted letters than did spies—but almost invariably the lovers used weaker ciphers! The spies and the lovers both used cryptography for the same reason: they wanted to be assured that, in the event that one of their messages was intercepted or opened by the wrong person, the letter’s contents would remain secret. Cryptography was used to increase privacy.

In recent years, the use of cryptography in business and commerce appears to have far eclipsed all uses of cryptography by all the world’s governments and militaries. These days, cryptography is used to scramble satellite television broadcasts, protect automatic teller networks, and guard the secrecy of practically every purchase made over the World Wide Web. Indeed, cryptography made the rapid commercialization of the Internet possible: without cryptography, it is doubtful that banks, businesses, and individuals would have felt safe doing business online. For all of its users, cryptography is a way of ensuring certainty and reducing risk in an uncertain world.

A Cryptographic Example

Let’s return to the example introduced at the beginning of this chapter. Here is that sample piece of plaintext again:

SSL is a cryptographic protocol

This message can be encrypted with an encryption algorithm to produce an encrypted message. The encrypted message is called a ciphertext.

In the next example, the message is encrypted using the Data Encryption Standard (DES).[79] The DES is a symmetric algorithm, which means that it uses the same key for encryption as for decryption. The encryption key is nosmis:

% des -e < text > text.des
Enter key: nosmis
Enter key again: nosmis
%

The result of the encryption is this encrypted message:[80]

% cat text.des
Ç'@%[»FÇ«;$TfiP∑|x¿EûóõÑ%ß+ö~·...aÜ"BÆuâw

As you can see, the encrypted message is nonsensical. But when this message is decrypted with the key nosmis, the original message is produced:

% des -d < text.des > text.decrypt
Enter key: nosmis
Enter key again: nosmis
% cat text.decrypt
SSL is a cryptographic protocol
%

If you try to decrypt the encrypted message with a different key, such as gandalf, the result is garbage:[81]

% des -d < text.des > text.decrypt
Enter key: gandalf
Enter key again: gandalf
Corrupted file or wrong key
% cat text.decrypt
±N%EÒR...f'"H;0ªõO>",,!_+í∞>

The only way to decrypt the encrypted message and get printable text is by knowing the secret key nosmis. If you don’t know the key, and you need the contents of the message, one approach is to try to decrypt the message with every possible key. This approach is called a key search attack or a brute force attack .

How easy is a brute force attack? That depends on the length of the key. Our sample message was encrypted with the DES algorithm, which has a 56-bit key. Each bit in the 56-bit key can be a 1 or a 0. As a result, there are 256—that is, 72,057,594,037,900,000—different keys. Although this may seem like a lot of keys, it really isn’t. If you could try a billion keys each second and could recognize the correct key when you found it (quite possible with a network of modern computers), you could try all possible keys in a little less than 834 days.

And, in fact, DES is even less secure than the example implies. The Unix des command does a very poor job of transforming a typed “key” into the key that’s actually used by the encryption algorithm. A typed key will typically include only the 96 printable characters, reducing the keyspace to 968 possible keys—this number is only one-tenth the size of 256. If you can search a billion keys a second, you could try all of these keys in only 83 days.

We’ll discuss these issues more thoroughly in Section 7.2.2 later in this chapter.

Cryptographic Algorithms and Functions

There are fundamentally two kinds of encryption algorithms:

Symmetric key algorithms

With these algorithms, the same key is used to encrypt and decrypt the message. The DES algorithm discussed earlier is a symmetric key algorithm. Symmetric key algorithms are sometimes called secret key algorithm s, or private key algorithms . Unfortunately, both of these names are easily confused with public key algorithms, which are unrelated to symmetric key algorithms.

Asymmetric key algorithms

With these algorithms, one key is used to encrypt the message and another key to decrypt it. A particularly important class of asymmetric key algorithms is public key systems. The encryption key is normally called the public key in these algorithms because it can be made publicly available without compromising the secrecy of the message or the decryption key. The decryption key is normally called the private key or secret key.

This technology was invented independently by academic cryptographers at Stanford University and by military cryptographers at England’s GCHQ, who called the techniques two-key cryptography. (The U.S. National Security Agency may have also invented and shelved the technology as a novelty, notes Carl Ellison.) This technology is a recent development in the history of cryptography.

Symmetric key algorithms are the workhorses of modern cryptographic systems. They are generally much faster than public key algorithms. They are also somewhat easier to implement. And it is generally easier for cryptographers to ascertain the strength of symmetric key algorithms. Unfortunately, symmetric key algorithms have three problems that limit their use in the real world:

  • For two parties to securely exchange information using a symmetric key algorithm, those parties must first exchange an encryption key. Alas, exchanging an encryption key in a secure fashion can be quite difficult.

  • As long as they wish to send or receive messages, both parties must keep a copy of the key. This doesn’t seem like a significant problem, but it is. If one party’s copy is compromised and the second party doesn’t know this fact, then the second party might send a message to the first party—and that message could then be subverted using the compromised key.

  • If each pair of parties wishes to communicate in private, then they need a unique key. This requires (N 2 - N)/2 keys for N different users. For 10 users that is 45 keys. This may not seem like much, but consider the Internet, which has perhaps 300,000,000 users. If you wanted to communicate with each of them, you’d need to store 299,999,999 keys on your system in advance. And if everyone wanted to communicate privately with everyone else, that would require 44,999,999,850,000,000 unique keys (almost 45 quadrillion)!

Public key algorithms overcome these problems. Instead of a single key, public key algorithms use two keys: one for encrypting the message, the other for decrypting the message. These keys are usually called the public key and the private key.

In theory, public key technology (illustrated in Figure 7-2) makes it relatively easy to send somebody an encrypted message. People who wish to receive encrypted messages will typically publish their keys in directories or otherwise make their keys readily available. Then, to send somebody an encrypted message, all you have to do is get a copy of her public key, encrypt your message, and send it to her. With a good public key system, you know that the only person who can decrypt the message is the person who has possession of the matching private key. Furthermore, all you really need to store on your own machine is your private key (though it’s convenient and unproblematic to have your public key available as well).

Public key cryptography can be used for encrypted messaging or for digital signatures

Figure 7-2. Public key cryptography can be used for encrypted messaging or for digital signatures

Public key cryptography can also be used for creating digital signatures . Similar to a real signature, a digital signature is used to denote authenticity or intention. For example, you can sign a piece of electronic mail to indicate your authorship in a manner akin to signing a paper letter. And, as with signing a bill of sale agreement, you can electronically sign a transaction to indicate that you wish to purchase or sell something. With public key technology, you use the private key to create the digital signature; others can then use your matching public key to verify the signature.

Unfortunately, public key algorithms have a significant problem of their own: they are computationally expensive.[82] In practice, public key encryption and decryption require as much as 1,000 times more computer power than an equivalent symmetric key encryption algorithm.

To get both the benefits of public key technology and the speed of symmetric encryption systems, most modern encryption systems actually use a combination. With hybrid public/private cryptosystems , slower public key cryptography is used to exchange a random session key , which is then used as the basis of a private (symmetric) key algorithm. (A session key is used only for a single encryption session and is then discarded.) Nearly all practical public key cryptography implementations are actually hybrid systems.

There is also a special class of functions that are almost always used in conjunction with public key cryptography: message digest functions. These algorithms are not encryption algorithms at all. Instead, they are used to create a “fingerprint” of a file or a key. A message digest function generates a seemingly random pattern of bits for a given input. The digest value is computed in such a way that finding a different input that will exactly generate the given digest is computationally infeasible. Message digests are often regarded as fingerprints for files. Most systems that perform digital signatures encrypt a message digest of the data rather than the actual file data itself.

The following sections look at these classes of algorithms in detail.



[78] Ironically, despite the fact that cryptography has been primarily used by the military, historically, the strongest publicly known encryption systems were invented by civilians. Encryption has long been used to protect commerce and hide secret romances, and at times these uses have dominated the political and military uses of cryptography. For more details, see Carl Ellison’s essay at http://world.std.com/~cme/html/timeline.html or read Kahn’s book.

[79] To be precise, we will use the DEA, the Data Encryption Algorithm, which conforms to the DES. Nearly everyone refers to it as the DES instead of the DEA, however.

[80] Modern encrypted messages are inherently binary data. Because of the limitations of paper, not all control characters are displayed.

[81] In the example, the des command prints the message “Corrupted file or wrong key” when we attempt to decrypt the file text.des with the wrong key. How does the des command know that the key provided is incorrect? The answer has to do with the fact that DES is a block encryption algorithm, encrypting data in blocks of 64 bits at a time. When a file is not an even multiple of 64 bits, the des command pads the file with null characters (ASCII 0). It then inserts at the beginning of the file a small header indicating how long the original file “really was.” During decryption, the des command checks the end of the file to make sure that the decrypted file is the same length as the original file. If it is not, then something is wrong: either the file was corrupted or the wrong key was used to decrypt the file. Thus, by trying all possible keys, it is possible to use the des command to experimentally determine which of the many possible keys is the correct one. But don’t worry: there are a lot of keys to try.

[82] The previous edition of this book used the words “quite slow” instead of “computationally expensive.” With modern computers, a public key operation can actually be quite fast—an encryption or decryption can frequently be performed in less than a second. But while that may seem fast, such a delay can be significant on a web server that is serving millions of web pages every day. This is why we use the phrase “computationally expensive.”