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

Updating System Software

Several factors go into the selection of a particular Unix operating system or application and the choice of which version of the software to run, but we won’t try to get into those issues here.[262] Once you’ve settled on which version of which software you’re going to install, however, it is imperative that you ensure that patches are available for all known security problems in the software, that you find those patches, and that you apply them. Similarly, once the system is up and running, you must be vigilant in learning about newly discovered security problems in your operating system and applications so you’ll be able to apply patches for them as they become available.

Installing a New Unix System

Because of the speed with which attackers discover new systems on the Internet, and the easy availability of attack scripts that can determine the operating system version of a remote Unix host and tailor its attacks against known bugs in that version, you must not put an unpatched Unix host onto the Internet in a way that makes it accessible to outsiders. Some commercial Unix vendors provide patch CD-ROMs quarterly on a subscription basis, but the very latest patches can usually be obtained only from the vendor’s web site.

The most secure way to patch a new installation is to download the patches to another computer that’s already connected to the Internet and updated with the latest security patches (perhaps a Mac or PC client that runs no server services). Once downloaded, they can be burned onto a CD-ROM or transferred to the new system using a local network connection, and then applied.

If no other Internet-connected host is available or suitable, the new host may have to be connected before the patches are applied. In this case, disable all network servers on the machine, and make the connection as brief as possible—only long enough to download the required patches—and then physically remove the machine from the network while the patches are applied. This process can be made even more secure if the machine’s connection can be protected by a stateful firewall or a router that implements network address translation, so that the only packets that can reach the new host are those associated with a connection initiated by the new host.

You can’t stay up to date with software that you don’t know you’ve installed. An important component of any ongoing updating process is to inventory your system and keep track of new applications that you’ve installed. Operating systems that use packages usually provide commands that will let you determine which packages you have installed. Source-based software management typically relies on keeping all of the source code to the installed applications in a single location where it can be easily found.

Learning About Patches

There are several avenues for learning about security problems and patches for operating systems and applications:

  • Every Unix operating system and most major applications, such as web servers, have an associated mailing list for announcements of new versions. Many maintain a separate list for announcements of security-related issues. Subscribe to these lists and pay attention to the messages

  • Several mailing lists collect and distribute security alerts for many products. These are listed in Appendix D. Subscribe to these lists (perhaps in digest form) and pay attention to the messages.

  • If your vendor provides a subscription patch CD-ROM service, consider subscribing. Although these CD-ROMs may not provide up-to-the-minute patches, they can save a lot of time when you are bringing up a new system by reducing the number of patches that need to be downloaded.

  • Automatic update systems compare installed packages with the latest versions of packages available on the vendor’s web site and report which packages are out of date. Also, most can be configured to automatically download and install the upgraded packages. This can be useful if you don’t change your configuration from the vendor defaults, and you trust the vendor to upgrade your system. Some can be run periodically through cron; others must be run manually on a regular basis. Here’s an example of searching for security updates in Debian GNU/Linux:[263] 

    # apt-get update                   (Update the current list of available packages)
Hit http://security.debian.org stable/updates/main Packages
Hit http://security.debian.org stable/updates/main Release
Hit http://security.debian.org stable/updates/contrib Packages
Hit http://security.debian.org stable/updates/contrib Release
Hit http://security.debian.org stable/updates/non-free Packages
Hit http://security.debian.org stable/updates/non-free Release
Get:1 http://security.debian.org woody/updates/main Packages [58.8kB]
Get:2 http://security.debian.org woody/updates/main Release [110B]
Get:3 http://security.debian.org woody/updates/contrib Packages [1490B]
Get:4 http://security.debian.org woody/updates/contrib Release [113B]
Get:5 http://security.debian.org woody/updates/non-free Packages [29B]
Get:6 http://security.debian.org woody/updates/non-free Release [114B]
Fetched 60.7kB in 0s (65.2kB/s)
Reading Package Lists... Done
Building Dependency Tree... Done
# apt-get -u upgrade            (Upgrade to latest packages with user confirmation)
langit:/home/alansz# apt-get -u upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be upgraded
  nis
1 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
Need to get 166kB of archives. After unpacking 221kB will be used.
Do you want to continue? [Y/n] y
Get:1 http://security.debian.org woody/updates/main nis 3.9-6.1 [166kB]
Fetched 166kB in 1s (158kB/s)
Preconfiguring packages ...
(Reading database ... 33243 files and directories currently installed.)
Preparing to replace nis 3.9-6 (using .../archives/nis_3.9-6.1_i386.deb) ...
Unpacking replacement nis ...

  • Finally, you can manually check the vendor’s web site on a regular basis for new versions of software.

Upgrading Distributed Applications

Under package management systems, upgrading a package is usually a very simple procedure. For example, here’s what you do to upgrade the bzip2-devel package on a system that uses the RPM package manager:

# ls -l *.rpm
-rw-r--r--    1 root     root        33708 Apr 16 23:15 bzip2-devel-1.0.2-2.i386.rpm
# rpm -K bzip2-devel-1.0.2-2.i386.rpm    
                   Check the package's integrity (checksum and
                                          signature).
bzip2-devel-1.0.2-2.i386.rpm: md5 OK
# rpm -Uvh bzip2-devel-1.0.2-2.i386.rpm 
                  Upgrade the package.
Preparing...      ########################################### [100%]
   1:bzip2-devel  ########################################### [100%]
# rpm -q bzip2-devel              
                  Confirm that the installed version is now 1.0.2-2.
bzip2-devel-1.0.2-2

Installing a Solaris security patch is similarly easy. After we downloaded patch 104489-15.tar.Z from http://sunsolve.sun.com/ we used the installpatch script bundled inside the patch archive to install the appropriate patch:

Checksums and Signatures

RPM packages incorporate two features to help verify their integrity. Every RPM file includes, as metadata, the MD5 cryptographic checksum of the packaged software. This checksum can detect file corruption or tampering. In addition, RPM files can be cryptographically signed using the GNU Privacy Guard (gpg) public key encryption software.

The -K (or —checksig) option to the rpm command performs integrity checking. It computes the MD5 checksum of the packaged software and compares it to the included checksum, and it tests the gpg signature for validity:

% rpm -K nfs-utils-0.3.3-5.i386.rpm
nfs-utils-0.3.3-5.i386.rpm: md5 OK

The word md5 implies that the MD5 check succeeded. The OK means that the gpg signature was verified. Adding the -v option provides additional useful output, notably information about exactly which key the package was signed with:

% rpm -K -v nfs-utils-0.3.3-5.i386.rpm
nfs-utils-0.3.3-5.i386.rpm:
MD5 sum OK: 4e3d971e40e494764d0639600bef86ce
gpg: Warning: using insecure memory!
gpg: Signature made Tue Apr 16 23:44:58 2002 CDT using DSA key ID DB42A60E
gpg: Good signature from "Red Hat, Inc <security@redhat.com>"

This package was signed by Red Hat’s security key (or something purporting to be that key—naturally, you must ensure that your gpg public keyring contains keys you trust for signing software).[264]

Debian’s package management system also incorporates gnupg signatures.

% ls *.tar.Z
104489-15.tar.Z
% uncompress *.Z
% su
Password: password

# tar xf 104489-15.tar
# cd 104489-15
# ls
.diPatch*          SUNWtltk/          backoutpatch*      postbackout*
Install.info*      SUNWtltkd/         installpatch*      postpatch*
README.104489-15   SUNWtltkm/         patchinfo*
# ./installpatch .
Checking installed patches...
Generating list of files to be patched...
Verifying sufficient filesystem capacity (exhaustive method)...
Installing patch packages...

Patch number 104489-15 has been successfully installed.
See /var/sadm/patch/104489-15/log for details
Executing postpatch script...

Patch packages installed:
  SUNWtltk
  SUNWtltkd
  SUNWtltkm

# showrev -p | egrep 104489
Patch: 104489-01  Obsoletes:   Packages: SUNWtltk, SUNWtltkd
Patch: 104489-14  Obsoletes:   Packages: SUNWtltk, SUNWtltkd, SUNWtltkm
Patch: 104489-15  Obsoletes:   Packages: SUNWtltk, SUNWtltkd, SUNWtltkm

If you’re using source-based management, upgrading involves either performing a CVS checkout of the updated source code or applying a patch file to the old source code to update it. In either case, the source code must then be recompiled and reinstalled. Here is an example of applying a patch to an application:

% ls -ld *
-rw-rw----    1 dunemush dunemush   188423 Jul 20 12:07 1.7.5-patch09
drwx------   10 dunemush dunemush     4096 Jul  4 16:15 pennmush/
% cd pennmush
% patch -p1 -s < ../1.7.5-patch09
% make
                   . . . source code compile messages . . . 
% make install
                   . . . installation messages . . . 
%

If you’re upgrading a server program, of course, you will need to stop the running server process and restart it to run the newly installed version—simply changing the server program on disk is not sufficient!

Backing Out and Backing Up

Not every upgrade is a panacea. Sometimes upgrades cause more problems than they solve, either because they break important functionality, or because they don’t provide the desired fix. It’s important to be able to revert to the pre-upgrade software if the upgrade proves troublesome.

There are two basic strategies for recovering from a bad upgrade. First, it may be possible to “back out” the patch and reinstall the earlier version. Under source-based management systems, the patch program can also be used to remove a previously applied patch, or the earlier version can be checked out from a CVS repository. It can be more difficult to cleanly back out a package. Although most package management software provides a way to overwrite an installed package with an earlier version, if the package dependencies have also been updated, older versions of the dependencies may also have to be located and installed.

A second strategy for source-based systems is to locally back up older versions of software. By keeping older versions of source code, it’s generally not difficult to reinstall the earlier version. Multiple versions can be kept in separate directories in /usr/src, or a version control system such as RCS or CVS can be used locally to track multiple versions of software in the same directory.

Perhaps the most reliable method is to perform a full backup of your system prior to the changes. Then, if the upgrade goes badly, you can restore your system to the prior state (see Chapter 18).

Sensitive Upgrades

Some upgrades are best performed when the system is in single-user mode. Although upgrading an application does not generally affect running processes, there are exceptions. Some programs dynamically load object code while running, and upgrading such programs without first stopping them can cause problems if the older version of the process loads the newer version of the dynamic code.

Similar caveats apply to updating shared libraries, and especially the shared C library. Upgrades to core shared libraries should always be installed in single-user mode.

Kernel upgrades also warrant single-user mode: when installing the new kernel, the new kernel will necessarily overwrite the old kernel. Installing a new kernel requires a system reboot anyway, however, so dropping down to single-user mode is not much more of an inconvenience.


[262] Except to urge you to consider the security features of the software as part of your decision-making process, of course.

[263] Linux distributions are particularly fond of this mechanism. Red Hat provides a system called up2date, SuSE provides Yast Online Update, Debian provides apt-get, and RPM-based distributions can take advantage of third-party software such as AutoRPM to automate updates.

[264] The “insecure memory” warning is produced because gpg is not installed setuid root on this system, and thus cannot lock memory pages to prevent them from being paged to disk. This is a concern when you’re using secret keys that might be revealed, but is not a concern if you are using only public keys to verify software.