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

Software Management Systems

A software management system is a set of tools and procedures for keeping track of which versions of which software you have installed, and whether any local changes have been made to the software or its configuration files. Without such a system, it is impossible to know whether a piece of software needs to be updated or what local changes have been made and need to be preserved after the update. Using some software management system to keep up to date is essential for security purposes, and useful for non-security upgrades as well.

Fortunately, nearly all Unix systems provide some form of software management for the core components of the operating system and the applications distributed with it. The most common approaches involve using management packages—precompiled executables and supporting files—and managing the software source code from which executables can be compiled and installed.

Mirror, Mirror

Whether you use packages or source code, you need to get the files from somewhere. Vendors typically make their applications available on the Internet—through the Web or through an anonymous FTP site. With very popular operating systems or applications, however, a single web site or FTP site often can’t keep up with the demand to download it, so many software vendors arrange to have other sites serve as mirrors for their site. Users are encouraged to download the software from the mirror site closest (in network geography) to them. In principle, all of the software on the vendor’s site is replicated to each mirror site on a regular (often daily) basis.

Mirror sites provide an important security benefit: they make the availability of software more reliable through redundancy. On the other hand, mirror sites also create some security concerns:

  • The administrators of the mirror site control their local copies of the software, and may have the ability to corrupt it, replace it with a Trojaned version, and so on. You must trust not only the vendor but also the administrators of the mirror site.

    If the vendor distributes digital signatures along with the software (for example, detached PGP signatures with source code archives, or gnupg signatures in rpm files), you will have added confidence that you’re receiving the software as released by the vendor, as long as you acquire the vendor’s public key directly—not through the mirror! Some update systems automatically check signatures before an update is applied.

    Note that several software vendors distribute MD5 checksums along with their software packages. MD5 checksums are useful for ensuring that the file was downloaded correctly. But MD5 checksums distributed with a program will not protect you from hostile code because an attacker who can replace the software package with a Trojaned version may also be able to replace the MD5 checksum with a checksum that will match the Trojan.

  • Even if you trust the mirror, daily updating may not be fast enough. If a critical security patch is released, you may not have time to wait 24 hours for your local mirror to be updated. In these cases, there is no substitute for downloading the patch directly from the vendor as soon as possible.

Using a mirror site is thus a trade-off between the convenience of being able to get a high-speed download when you want it, and of possibly extending your trust to a third party.

Package-Based Systems

A typical package file is a file containing a set of executable programs, already compiled, along with any supporting files such as libraries, default configuration files, and documentation. Under most packaging systems, the package also contains some metadata, such as:

  • Version information for the software it contains

  • Information about compatible operating system versions or hardware architectures

  • Lists of other packages that the package requires

  • Lists of other packages with which the package conflicts

  • Lists of which included files are configuration files (or are otherwise likely to be changed by users once installed)

  • Commands to run before, during, or after the included files are installed

The other important component of a package-based system is a database containing information about which versions of which packages have been installed on the system.

Package-based systems are easy to use: with a simple command or two, a system administrator can install new software or upgrade her current software when a new or patched version is released. Because the packaged executables are already compiled for the target operating system and hardware platform, the administrator doesn’t have to spend time building (and maybe even porting) the application.

On the other hand, packages are compiled to work on the typical installation of the operating system, and not necessarily on your installation. If you need to tune your applications to work with some special piece of hardware, adapt them to an unusual authentication system, or simply compile them with an atypical configuration setting, source code will likely be more useful to you. This is often the case with the kernel, for example.

Commercial Unix distributions that don’t provide source code are obvious candidates for package-based management. For example, Solaris 2.x provides the pkgadd, pkgrm, pkginfo, and showrev commands (and others) for adding, removing, and querying packages from the shell, and admintool for managing software graphically.

Package management isn’t only for commercial Unix. Free software Unix distributions also provide package management systems to make it easier for system administrators to keep the system up to date. Several Linux distributions have adopted the RPM Package Manager (RPM) system.[259] This system uses a single command, rpm, for all of its package management functions. Debian GNU/Linux uses an alternative package management system called dpkg. The BSD-based Unix systems focus on source-based updates, but also provide a collection of precompiled packages that are managed with the pkg_add, pkg_delete, and pkg_info commands.

Source-Based Systems

In contrast to package-based systems, source-based systems focus on helping the system administrator maintain an up-to-date copy of the operating system’s or application’s source code, from which new executables can be compiled and installed. Source-based management has its own special convenience: a source-based update comes in only a single version, as opposed to compiled packages, which must be separately compiled and packaged for each architecture or operating system on which the software runs. Source-based systems can also be particularly useful when it’s necessary to make local source code changes.

From a security standpoint, building packages from source code can be a mixed blessing. On the one hand, you are free to inspect the source code and determine if there are any lurking bugs or Trojan horses. In practice, such inspection is difficult and rarely done,[260] but the option exists. On the other hand, if an attacker can get access to your source code, it is not terribly difficult for the attacker to add a Trojan horse of her own! To avoid this problem, you need to be sure both that the source code you are compiling is for a reliable system and that you have the genuine source code.[261]

Source code and patches

The simplest approach to source management is to keep application source code available on the system and recompile it whenever it’s changed. Most Unix systems use the /usr/src and /usr/local/src hierarchies to store source code to distributed and third-party software, respectively. When a patch to an application is released, it typically takes the form of a patch diff, a file that describes which lines in the old version should be changed, removed, or added to in order to produce the new version. The diff program produces these files, and the patch program is used to apply them to an old version to create the new version. After patching the source code, the system administrator recompiles and reinstalls the application.

Source Packages

Although most users of Linux distributions that use the rpm or dpkg package management systems may never use one, both systems support packages containing source code rather than precompiled executables. Source packages install themselves in a special location, and include metadata that describes how to automatically compile and install the application from the source.

For example, FreeBSD and related versions of Unix distribute many applications in their ports collection. An application in the ports collection consists of the original source code from the application’s author, along with a set of patches that have been applied to better integrate the application into the BSD environment. The makefiles included in the ports system automatically build the application, install it, and then register the application’s files with the BSD pkg_add command.

This approach is widely used for maintaining third-party software on FreeBSD systems.

CVS

Another approach to source management is to store the source code on a server using a source code versioning system such as the Concurrent Versions System (CVS), and configure the server to allow anonymous client connections. Users who want to update their source code to the latest release use the CVS program to “check out” the latest patched version from the remote server’s repository. The updated code can then be compiled and installed.

An advantage of CVS is that the system makes it easy for sites to maintain their own local modifications to an otherwise large and unwieldy system. CVS will detect the local modifications and reapply them each time a new version of the source code is downloaded.

FreeBSD, NetBSD, and OpenBSD use CVS to distribute and maintain their core operating system software. In addition, tens of thousands of open source software projects maintain CVS servers of their own, or are hosted at sites such as sourceforge.net that provide CVS respositories.


[259] In its early days, RPM stood for “Red Hat Package Manager,” but the name has since been changed to reflect its popularity on other distributions of Linux as well.

[260] Moreover, source inspection is rarely done correctly! Knowing how to program is not the same as knowing how to audit code for security problems.

[261] Even so, there are an increasing number of cases in which source code distribution was successfully attacked and a Trojan horse was incorporated into code that was subsequently distributed. Ironically, both cases involved security-related software. In one case, a Trojan horse was incorporated into the source code for the tcpwrappers suite of programs. In another case, a Trojan horse was incorporated into the makefiles that build OpenSSH.