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

File Attributes and Permissions

Now that we have a basic understanding of how filesystems work, we’ll turn our attention to understanding how filesystems influence the security of a Unix system. Nearly all of this discussion will be concerned with the metadata that a filesystem contains—the filenames, permissions, timestamps, and access control attributes.

Exploring with the ls Command

You can use the ls command to list all of the files in a directory. For instance, to list all the files in your current directory, type:

% ls
instructions  invoice       letter       more-stuff   notes      stats
%

Actually, ls alone won’t list all of the files. Files and directories beginning with a dot (“.”) are hidden from the ls command but are shown if you use ls -a:

% ls -a
.  ..  .indent  instructions  invoice  letter  notes  more-stuff  stats
%

The entries for “.” and “..” refer to the current directory and its parent directory, respectively. The file .indent is a hidden file. If you use ls -A instead of ls -a, you’ll see hidden files, but “.” and “..” will not be shown.

You can get a more detailed listing by using the ls -lF command:

% ls -lF
total 161
-rw-r--r-- 1 sian    user          505 Feb  9 13:19 instructions
-rw-r--r-- 1 sian    user         3159 Feb  9 13:14 invoice
-rw-r--r-- 1 sian    user         6318 Feb  9 13:14 letter
-rw------- 1 sian    user        15897 Feb  9 13:20 more-stuff
-rw-r----- 1 sian    biochem      4320 Feb  9 13:20 notes
-rwxr-xr-x 1 sian    user       122880 Feb  9 13:26 stats*
%

The first line of output generated by the ls command (total 161 in the example above) indicates the number of KBs taken up by the files in the directory. Each of the other lines of output contains the fields, from left to right, as described in Table 6-2.

Table 6-2. ls output

Field contents

Meaning

-

The file’s type; for regular files, this field is always a dash

rw-r—r—

The file’s permissions

1

The number of “hard” links to the file; the number of “names” for the file

sian

The name of the file’s owner

user

The name of the file’s group

505

The file’s size, in bytes

Feb 9 13:19

The file’s modification time

instructions

The file’s name

The ls -F option makes it easier for you to understand the listing by printing a special character after the filename to indicate what it is, as shown in Table 6-3.

Table 6-3. ls -F tag meanings

Symbol

Meaning

(blank)

Regular file

*

File has the execute bit set, typical of executable programs or command files

/

Directory

=

Socket

@

Symbolic link

>

A door, which is a special construct in Sun’s Solaris that is currently in development; used for interprocess communication

|

A FIFO (a First-In, First-Out buffer, which is a special kind of named pipe)

%

A whiteout[a]

[a] If you have two filesystems mounted in a union filesystem and the upper-layer filesystem has an empty directory, that directory will white out the entries in the lower-layer filesystem. This is indicated by the “%” whiteout character.

Thus, in the directory shown earlier, the execute bit of the file stats is set; the rest of the files are regular files.

The ls command has dozens of options. Because different people typically like to see different pieces of information when they list files, you may wish to read the manual page for the ls command that is on your system and then set up aliases so that you will have these options run by default when you type “ls.” For instance, Spaf has an alias “lf” that runs ls with the options -FA, an alias “ll” that runs ls with the options -FAl, and “lb” that runs ls with the options -FAbx (the -b switch shows printable octal representations of nonprinting characters, and the -x switch sorts filenames across rows rather than down columns).

File Times

The times shown with the ls -l command are the modification times of the file contents, frequently called the file’s mtime. You can obtain the time of last access (the atime ) by providing the -u option (for example, by typing ls -lu). These times are automatically updated by the Unix operating system.

Knowing when a file was last modified or accessed can be important in many circumstances. For example, if a person has been using your account, you can look at the mtimes of files to infer which files the person modified. Unfortunately, the mtime and atime can’t strictly be trusted, because they can be changed by the file’s owner or the superuser by calling a function (utimes( )) within the Unix kernel. This function exists so that archive programs like tar and unzip can restore a file’s modification time in addition to its contents. Additionally, the times reflect the system clock at the time of access or modification, so if the clock is incorrect or is changed, the times may not be accurate.

Because a file’s mtime and atime cannot be trusted, system administrators and security professionals need to be in the habit of checking the inode change time (ctime ) using the ls -c option; for example, ls -lc. As with the mtime and the atime, the ctime is automatically updated by the operating system—in this case, whenever a change is made to the inode of the file. But unlike with mtime and atime, unprivileged users cannot change a file’s ctime. The ctime reflects the time of last writing, protection change, or change of owner. An attacker may change the mtime or atime of a file, but the ctime will usually be correct.

Note that we said “usually.” A clever attacker who gains superuser status can change the system clock and then touch the inode to force a misleading ctime on a file. Furthermore, an attacker can change the ctime by writing to the raw disk device and bypassing the operating system checks altogether. And if you are using Linux with the ext2 filesystem, an attacker can modify the inode contents directly using the debugfs command.

For this reason, if the superuser account on your system has been compromised, you should not assume that any of the three times stored with any file or directory are correct.

Tip

Some programs will change the ctime on a file without actually changing the file itself. This can be misleading when you are looking for suspicious activity. The file command is one such offender. The discrepancy occurs because file opens the file for reading to determine its type, thus changing the atime on the file. By default, most versions of file then reset the atime to its original value, but in so doing change the ctime. Some security scanning programs use the file program within them (or employ similar functionality), and this may result in wide-scale changes in ctime unless they are run on a read-only version of the filesystem.

File Permissions

The file permissions on each line of the ls listing tell you what the file is and what kind of file access (that is, the ability to read, write, or execute) is granted to various users on your system.

Here are two examples of file permissions:

-rw-------
drwxr-xr-x

The first character of the file’s mode field indicates the type of file (described in Table 6-4).

Table 6-4. File types

Contents

Meaning

-

Plain file

d

Directory

D

Solaris door construct

c

Character device (tty or printer)

b

Block device (usually disk or CD-ROM)

l

Symbolic link (BSD or SVR4)

s

Socket (BSD or SVR4)

= or p

FIFO (System V, Linux)

The next nine characters taken in groups of three indicate who on your computer can do what with the file. There are three kinds of permissions:

r

Permission to read

w

Permission to write

x

Permission to execute

Similarly, there are three classes of permissions:

Owner

The file’s owner

Group

Users who are in the file’s group

Other

Everybody else on the system (except the superuser)

In the ls -l command privileges are illustrated graphically (see Figure 6-2).

Basic permissions

Figure 6-2. Basic permissions

The terms read, write, and execute have very specific meanings for files, as shown in Table 6-5.

Table 6-5. File permissions

Character

Permission

Meaning

r

Read

Read access means exactly that: you can open a file with the open( ) system call and you can read its contents with read( ).

w

Write

Write access means that you can overwrite the file with a new one or modify its contents. It also means that you can use write( ) to make the file longer, or truncate( ) or ftruncate( ) to make the file shorter.

x

Execute

If a file’s execute bits are set, you can run it by typing its pathname (or by running it with one of the family of exec( ) system calls). How the program is executed depends on the first two bytes of the file.

The first two bytes of an executable file are assumed to be a magic number indicating the nature of the file. Some numbers mean that the file is a certain kind of machine code file. The special two-byte sequence “#!” means that it is an executable script of some kind (the remainder of the first line specifies the program that should execute the script). Anything with an unknown value is assumed to be a shell script and is executed accordingly.

File permissions apply to devices, named sockets, and FIFOs exactly as they do for regular files. If you have write access, you can write information to the file or other object; if you have read access, you can read from it; and if you don’t have either access, you’re out of luck.

File permissions do not apply to symbolic links. Whether you can read the contents of a file pointed to by a symbolic link depends on that file’s permissions, not the link’s. In fact, symbolic links are almost always created with a file permission of “rwxrwxrwx” (or mode 0777, as explained later in this chapter). These file permissions are then ignored by the operating system.

Note the following facts about file permissions:

  • You can have execute access without having read access. In such a case, the program can be run by a person without giving them permission to read the contents of the file or make a copy of the program. This ability is useful in case you wish to hide the function of a program, but you should not depend on this behavior, as there are ways on some operating systems to circumvent the protection.

  • If you have read access but not execute access, you can then make a copy of the file and run it for yourself. The copy, however, will be different in two important ways: it will have a different absolute pathname, and it will be owned by you, rather than by the original program’s owner.

  • On some versions of Unix, an executable command script must have both its read bit and its execute bit set to allow people to run it.

On Solaris systems, there may be an additional character following the permission characters:

-rwx--x--x+ 3 spaf spaf 24219 May 17 00:52 example

The + symbol indicates that this file (or other item) has an extended ACL associated with it. An Access Control List (ACL) provides a more comprehensive set of permissions on the file than can be described with the single user/single group model. ACLs are discussed later in this chapter.

Because file permissions determine who can read and modify the information stored in your files, they are your primary method for protecting the data that you store on your Unix system.

Most people think that file permissions are pretty basic stuff. Nevertheless, many Unix systems have had security breaches because their file permissions are not properly set, and several provide automated tools for checking the permissions of important system files on a regular basis.

Tip

Sun’s NFS servers allow a client to read any file that has either the read or the execute permission set. They do so because there is no difference, from the NFS server’s point of view, between a request to read the contents of a file by a user who is using the read( ) system call and a request to execute the file by a user who is using the exec( ) system call. In both cases, the contents of the file need to be transferred from the NFS server to the NFS client. (For a detailed description, see Chapter 15.)

A file permissions example

Consider the directory listing presented earlier in this chapter:

% ls -lF
total 161
-rw-r--r-- 1 sian     user        505 Feb  9 13:19 instructions
-rw-r--r-- 1 sian     user       3159 Feb  9 13:14 invoice
-rw-r--r-- 1 sian     user       6318 Feb  9 13:14 letter
-rw------- 1 sian     user      15897 Feb  9 13:20 more-stuff
-rw-r----- 1 sian     biochem    4320 Feb  9 13:20 notes
-rwxr-xr-x 1 sian     user     122880 Feb  9 13:26 stats*
-------r-x 1 sian     user     989987 Mar  6 08:13 weird-file
%

In this example, any user on the system can read the files instructions, invoice, letter, or stats because they all have the letter r in the “other” column of the permissions field. The file notes can be read only by user sian or by users who are in the biochem group. And only sian can read the information in the file more-stuff.

A more interesting set of permissions is present on weird-file. User sian owns the file but cannot access it. Members of group user also are not allowed access. However, any user except sian and who is also not in the group user can read and execute the file.[66] Some variant of these permissions is useful in some cases where you want to make a file readable or executable by others, but you don’t want to accidentally overwrite or execute it yourself. If you are the owner of the file and the permissions deny you access, it does not matter if you are in the group, or if other bits are set to allow the access.

Of course, the superuser can read any file on the system, and anybody who knows Sian’s password can log in as sian and read her files (including weird-file, if sian changes the permissions first).

Directory Permissions

Unix stores the contents of directories in nodes that are similar to the nodes used for regular files, but they are specially marked so that they can be modified only by the operating system.

As with other files, directories have a full complement of security attributes: owner, group, and permission bits. But because directories are interpreted in a special way by the filesystem, the permission bits have special meanings (see Table 6-6).

Table 6-6. Permissions for directories

Contents

Permission

Meaning

r

Read

You can use the opendir( ) and readdir( ) functions (or the ls command) to find out which files are in the directory.

w

Write

You can add, rename, or remove entries in that directory.

x

Execute

You can stat the contents of a directory (e.g., you can determine the owners and the lengths of the files in the directory). You also need execute access to a directory to make that directory your current directory or to open files inside the directory (or in any of the directory’s subdirectories).

If you want to prevent other users from reading the contents of your files, you have two choices:

  • You can set the permission of each file to 0600, so only you have read/write access.

  • You can put the files in a directory and set the permission of that directory to 0700, which prevents other users from accessing the files in the directory (or in any of the directory’s subdirectories) unless there is a hard link to each file from somewhere else.

Note the following:

  • You must have execute access for a directory to make it your current directory (via cd or chdir) or to change to any directory beneath (contained in) that directory.

  • If you do not have execute access to a directory, you cannot access the files within that directory, even if you own them.

  • If you have execute access to a directory but do not have read access, you cannot list the names of files in the directory (e.g., you cannot read the contents of the directory). However, if you have access to individual files, you can run programs in the directory or open files in it. Some sites use this technique to create secret files—files that users can access only if they know the files’ full pathnames.

  • To unlink a file from a directory, you need to have write and execute access to that directory, but not to the file itself.

  • If you have read access to a directory but do not have execute access, you can display a short listing of the files in the directory (ls); however, you will not be able to find out anything about the files other than their names and inode numbers (ls -i) because you can’t stat the files. Remember that the directory itself contains only name and inode information.

    This processing can cause quite a bit of confusion if you are not expecting it. For example:

    % ls -ldF conv
    dr------ 4 rachel      1024 Jul  6 09:42 conv/ 
    % ls conv
    3ps.prn bizcard.ps letterhead.eps retlab.eps 
    % ls -l conv
    conv/3ps.prn not found 
    conv/bizcard.ps not found 
    conv/letterhead.eps not found 
    conv/retlab.eps not found 
    total 0
    %


[66] Also, as we’ll see later, the user who owns this directory can delete any of the files.