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

Remote Procedure Call (RPC)

The fundamental building block of all network information systems is a mechanism for performing remote operations. Abstractly, this can be done via either messages or procedure calls; systems have been developed using both paradigms, and the capabilities are equivalent. Sun’s software engineers chose to use the abstraction of procedure calls. This mechanism, usually called RPC, allows a program running on one computer to more or less transparently execute a function that is actually running on another computer.

RPC allows programs to be distributed so that a computationally intensive algorithm can be run on a high-speed computer, a remote sensing device can be run on another computer, and the results can be compiled on a third. RPC also makes it easy to create network-based client/server programs. The clients and servers communicate with each other using remote procedure calls.

The RPC system was developed by Sun Microsystems for use with NIS and NFS. Sun’s RPC uses a system called XDR (external data representation) to represent binary information in a uniform manner and bit order. XDR allows a program running on a computer with one byte order, such as a SPARC workstation, to communicate seamlessly with a program running on a computer with an opposite byte order, such as a workstation with an Intel x86 microprocessor. RPC messages can be sent with either the TCP or UDP IP protocols (currently, the UDP version is more common). After their creation by Sun, XDR and RPC were reimplemented by the University of California at Berkeley and are now freely available.[178]

Sun’s RPC is not unique. A different RPC system is used by the Open Software Foundation’s Distributed Computing Environment (DCE). Yet another RPC system was proposed by the Object Management Group. Named CORBA (Common Object Request Broker Architecture), this system is optimized for RPC between object-oriented programs written in C++ or SmallTalk. Java programmers use Remote Method Invocation (RMI). There have also been a number of research RPC systems developed before and after Sun’s.

In the following sections, we’ll discuss the Sun RPC mechanism, as it seems to be the most widely used. The continuing popularity of NFS (described in Chapter 15) suggests that Sun RPC will be in widespread use for some time to come.

Sun’s portmap/rpcbind

For an RPC client to communicate with an RPC server, many things must happen:

  • The RPC client must be running.

  • The RPC server must be running on the server machine (or it must be automatically started when the request is received).

  • The client must know on which host the RPC server is located.

  • The client and the server must agree to communicate on a particular TCP or UDP port.

The simplest way to satisfy this list of conditions is for the Unix computer to start the server when the computer boots, for the server to run on a well-known port, and for the port numbers to be predefined. This is the approach that Unix takes with standard Internet services such as Telnet and SMTP.

The approach that Sun took for RPC was different. Instead of having servers run on well-known ports, Sun developed a program named portmap in SunOS 4.x, and renamed rpcbind in Solaris 2.x. Throughout this book, we will refer to the program as the portmapper.[179]

When an RPC server starts, it dynamically obtains a free UDP or TCP port, then registers itself with the portmapper. When a client wishes to communicate with a particular server, it contacts the portmapper process, determines the port number used by the server, and then initiates communication.

The portmapper approach has the advantage that you can have many more RPC services (in theory, 232) than there are TCP or UDP port numbers (216).[180] In practice, however, the greater availability of RPC server numbers has not been very important. Indeed, one of the most widely used RPC services, NFS, usually has a fixed port of 2049.

The portmapper program also complicates building Internet firewalls because you almost never know in advance the particular port that will be used by RPC-based services. (This is mitigated by the realization that you almost always want to deny access to your RPC-based services to anyone outside your firewall.)

RPC Authentication

Client programs contacting an RPC server need a way to authenticate themselves to the server so that the server can determine what information the client should be able to access, and what functions should be allowed. Without authentication, any client on the network that can send packets to the RPC server could access any function. In most environments this is not something you want to allow.

There are several different forms of authentication available for RPC, as described in Table 13-1. Not all authentication systems are available in all versions of RPC.

Table 13-1. RPC authentication options

System

Authentication technique

Comments

AUTH_NONE

None

No authentication. Anonymous access.

AUTH_UNIX[a]

RPC client sends the Unix UID and GIDs for the user

Not secure. Server implicitly trusts that the user is who the user claims to be.

AUTH_DES

Authentication based on public key cryptography and DES

Reasonably secure.

AUTH_KERB

Authentication based on Kerberos

Reasonably secure, but requires that you properly set up a Kerberos server. AUTH_KERB is not universally available.

[a] AUTH_UNIX is called AUTH_SYS in at least one version of Sun Solaris.

AUTH_NONE

Live fast, die young. AUTH_NONE is bare-bones RPC with no user authentication. You might use it for services that require and provide no useful information, such as time of day. On the other hand, why do you want other computers on the network to be able to find out the setting of your system’s time-of-day clock? (Furthermore, because the system’s time of day is used in a variety of cryptographic protocols, even that information might be usable in an attack against your computer.) Besides, NTP is a much better protocol to use for obtaining the time for any legitimate purpose (see the sidebar Telling Time in Chapter 12). Do not use AUTH_NONE.

AUTH_UNIX

AUTH_UNIX was the only authentication system provided by Sun through Release 4.0 of the SunOS operating system, and it is the only form of RPC authentication offered by many Unix vendors. It is widely used. Unfortunately, it is fundamentally unsecure.

With AUTH_UNIX, each RPC request is accompanied with a UID and a set of GIDs[181] for authentication. The server implicitly trusts the UID and GIDs presented by the client and uses this information to determine if the action should be allowed. Anyone with access to the network can craft an RPC packet with any arbitrary values for UID and GID. Obviously, AUTH_UNIX is not secure because the client is free to claim any identity, and there is no provision for checking by the server.

In recent years, Sun has changed the name AUTH_UNIX to AUTH_SYS. Nevertheless, it’s still the same system.

AUTH_DES

AUTH_DES is the basis of Sun’s “Secure RPC” (described in some detail later in this chapter). AUTH_DES uses a combination of secret key and public key cryptography to allow security in a networked environment. It was developed several years after AUTH_UNIX, and for some time was not widely available on Unix platforms other than Sun’s SunOS and Solaris 2.x operating systems. AUTH_DES is now available in modern BSD systems and systems that use the GNU C library (such as Linux), as well as HP-UX and AIX, but the availability of applications (such as NFS clients and servers) that can use AUTH_DES on these platforms varies.

AUTH_KERB

AUTH_KERB is a modification to Sun’s RPC system that allows it to interoperate with MIT’s Kerberos system for authentication. Although Kerberos was developed in the mid 1980s, AUTH_KERB authentication for RPC was not incorporated into Sun’s RPC until the early 1990s. Solaris 8 and 9 include Kerberos client support, and Solaris 9 includes Kerberos server support as well. We describe Kerberos in Chapter 14.

Warning

Carefully review the RPC services that are configured into your system for automatic start when the system boots, or for automatic dispatch from the inetd (see Section 12.1.2). If you don’t need a service, disable it. In particular, if your version of the rexd service cannot be forced into accepting only connections authenticated with Kerberos or Secure RPC, then it should be turned off. The rexd daemon (which executes commands issued with the on command) is otherwise easily fooled into executing commands on behalf of any non-root user.


[178] And all of those implementations were found to have a buffer overflow vulnerability in 2002 (see http://www.cert.org/advisories/CA-2002-25.html for more information). Fortunately, vendors quickly released patched XDR code.

[179] A rewritten portmapper for SunOS 4.1.x, HP-UX 9.0, AIX 3.x/4.x, and Digital Unix (OSF/1) by Wietse Venema provided superior access control for these older systems. Most modern systems now distribute portmappers that can be configured to restrict access using /etc/hosts.allow and /etc/hosts.deny. However, it is still possible to locate RPC services by scanning for them directly, without asking the portmapper.

[180] Of course, you can’t really have 232 RPC services because there aren’t enough programmers to write them, or enough computers and RAM for them to run. The reason for having 232 different RPC service numbers available was that different vendors could pick RPC numbers without the possibility of conflict. A better way to reach this goal would have been to allow RPC services to use names so that companies and organizations could have registered their RPC services using their names as part of the service names.

[181] Some versions of RPC present 8 additional GIDs, while others present up to 16.