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

Managing Services Securely

Once you have deployed a Unix server on a network, it is important that you manage it securely. You should periodically monitor your server and the network for potential problems or abuse. Most network topologies provide three locations for monitoring:

  • You can monitor on the hosts themselves, either by monitoring the packets as they enter or leave the system, or by monitoring servers that are running on the system.

  • You can monitor the local area network. If you have an Ethernet hub on your network, you can monitor by attaching another computer to the hub that is running a network monitor or packet sniffer. If you have a switched network, you will need to create a mirror port or monitor point.[170]

  • You can monitor information entering or leaving your network at the point where your network connects to other networks.

Most monitoring involves one or at most two of these systems; the most secure networks combine all three.

You may also wish to employ other methods, such as network scanning, to detect vulnerabilities before attackers do so.

Monitoring Your Host with netstat

You can use the netstat command to list all of the active and pending TCP/IP connections between your machine and every other machine on the Internet. This command is very important if you suspect that somebody is breaking into your computer or using your computer to break into another one. netstat lets you see which machines your machine is talking to over the network. The command’s output includes the host and port number of each end of the connection, as well as the number of bytes in the receive and transmit queues. If a port has a name assigned in the /etc/services file, netstat will print it instead of the port number.

Normally, the netstat command displays Unix domain sockets in addition to IP sockets. You can restrict the display to IP sockets only by using the -f inet (or -A inet in some versions) option.

Sample output from the netstat command looks like this:

% netstat -f inet
Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0      0  R2-INTERNAL.imap       KITCHEN.1922           ESTABLISHED
tcp4       0  31400  r2.http                z06.nvidia.com.27578   ESTABLISHED
tcp4       0      0  r2.http                66.28.250.172.2020     TIME_WAIT
tcp4       0     20  r2.ssh                 h00045a28e754.ne.3301  ESTABLISHED
tcp4       0      0  r2.http                goob03.goo.ne.jp.35251 TIME_WAIT
tcp4       0      0  r2.1658                ftp2.sunet.se.8648     ESTABLISHED
tcp4       0      0  R2-INTERNAL.imap       G3.1472                FIN_WAIT_2
tcp4       0      0  r2.http                66.28.250.172.1574     TIME_WAIT
tcp4       0      0  r2.1657                ftp2.sunet.se.ftp      ESTABLISHED
tcp4       0      0  r2.1656                rpmfind.speakeas.59355 TIME_WAIT
tcp4       0      0  r2.1655                rpmfind.speakeas.ftp   TIME_WAIT
tcp4       0      0  r2.http                host-137-16-220-.1600  TIME_WAIT
tcp4       0      0  r2.http                z06.nvidia.com.25805   FIN_WAIT_2
tcp4       0      0  r2.http                z06.nvidia.com.25803   FIN_WAIT_2
tcp4       0      0  r2.http                z06.nvidia.com.25802   FIN_WAIT_2
tcp4       0      0  r2.1654                K1.VINEYARD.NET.domain TIME_WAIT
tcp4       0      0  R2-INTERNAL.imap       G3.1471                TIME_WAIT
tcp4       0      0  r2.ssh                 h00045a28e754.ne.3300  ESTABLISHED
tcp4       0      0  localhost.imap         localhost.1544         ESTABLISHED
tcp4       0      0  localhost.1544         localhost.imap         ESTABLISHED
tcp4       0      0  r2.imaps               h00045a28e754.ne.3285  ESTABLISHED
tcp4       0      0  R2-INTERNAL.ssh        KITCHEN.1190           ESTABLISHED
tcp4       0      0  R2-INTERNAL.netbios-ss KITCHEN.1031           ESTABLISHED
%

Tip

The netstat program displays only abridged hostnames, but you can use the -n flag to display the IP address of the foreign machine, and then look up the IP address using another tool such as host. This is probably a good idea anyway, as IP addresses are harder to hide and the hostname lookup itself may alert an attacker that you are monitoring them.

The first line indicates an IMAP connection with the computer called KITCHEN. This connection originated on port 1922 of the remote machine. The second line indicates an in-process HTTP connection with the host z06.nvidia.com. The third line is an HTTP download that has entered the TIME_WAIT state.[171] The subsequent lines are various TCP connections to and from other machines. These lines all begin with the letters “tcp4”, indicating that they are TCP servers running on top of IPv4.

With the -a option, netstat will also print a list of all of the TCP and UDP sockets to which programs are listening. Using the -a option will provide you with a list of all the ports that programs and users outside your computer can use to enter the system via the network.

% netstat -f inet -a
Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
...
Previous netstat printout
...
tcp4       0      0  *.amidxtape            *.*                    LISTEN
tcp4       0      0  *.amandaidx            *.*                    LISTEN
tcp4       0      0  *.smtps                *.*                    LISTEN
tcp4       0      0  *.pop3s                *.*                    LISTEN
tcp4       0      0  *.imaps                *.*                    LISTEN
tcp4       0      0  *.imap                 *.*                    LISTEN
tcp4       0      0  *.pop3                 *.*                    LISTEN
tcp4       0      0  *.time                 *.*                    LISTEN
tcp4       0      0  *.ftp                  *.*                    LISTEN
tcp4       0      0  *.3306                 *.*                    LISTEN
tcp4       0      0  *.smtp                 *.*                    LISTEN
tcp4       0      0  *.gdomap               *.*                    LISTEN
tcp4       0      0  R2-INTERNAL.netbios-ss *.*                    LISTEN
tcp4       0      0  r2.netbios-ssn         *.*                    LISTEN
tcp4       0      0  *.ssh                  *.*                    LISTEN
tcp4       0      0  *.printer              *.*                    LISTEN
tcp4       0      0  *.1022                 *.*                    LISTEN
tcp4       0      0  *.nfsd                 *.*                    LISTEN
tcp4       0      0  *.1023                 *.*                    LISTEN
tcp4       0      0  *.sunrpc               *.*                    LISTEN
tcp4       0      0  localhost.domain       *.*                    LISTEN
tcp4       0      0  BLAST.domain           *.*                    LISTEN
tcp4       0      0  R2-INTERNAL.domain     *.*                    LISTEN
tcp4       0      0  r2.domain              *.*                    LISTEN
udp4       0      0  localhost.4122         *.*                    
udp4       0      0  R2-INTERNAL.netbios-dg *.*                    
udp4       0      0  R2-INTERNAL.netbios-ns *.*                    
udp4       0      0  r2.netbios-dgm         *.*                    
udp4       0      0  r2.netbios-ns          *.*                    
udp4       0      0  localhost.ntp          *.*                    
udp4       0      0  BLAST.ntp              *.*                    
udp4       0      0  R2-INTERNAL.ntp        *.*                    
udp4       0      0  r2.ntp                 *.*                    
udp4       0      0  localhost.domain       *.*                    
udp4       0      0  BLAST.domain           *.*                    
udp4       0      0  R2-INTERNAL.domain     *.*                    
udp4       0      0  r2.domain              *.*                    
%

The lines in the middle of the listing that end with “LISTEN” indicate TCP servers that are running and listening for incoming communications. Clearly, this computer is running a lot of services. Some of the ports on which this computer is listening have no matching name in the /etc/services file, and are therefore listed only by their numbers (i.e., 1022, 1023). This should be a cause for further investigation. Unfortunately, netstat will not give you the name of the program that is listening on the socket.

To determine which process is listening on port 1022 and port 1023, we can use the lsof [172] command:

r2# lsof -i:1022
COMMAND   PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
rpc.statd 107 root    4u  IPv4 0xd5faa700      0t0  TCP *:1022 (LISTEN)
r2# lsof -i:1023
COMMAND PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
mountd   98 root    3u  IPv4 0xd5e2b500      0t0  UDP *:1023
mountd   98 root    4u  IPv4 0xd5faab40      0t0  TCP *:1023 (LISTEN)
r2#

The rpc.statd program has a history of security vulnerabilities (See http://www.cert.org/advisories/CA-2000-17.html). The mountd program is part of the NFS system; it also has a history of security vulnerabilities (see http://www.cert.org/advisories/CA-1998-12.html. Fortunately, all known vulnerabilities in both of these programs have been fixed.[173] Perhaps even more importantly, the r2 computer is protected with a host-based firewall that blocks all connections to port 1022 and 1023 that originate on the Internet.

We can verify that r2’s firewall is in proper operation by probing the system with the nmap [174] command from an outside host:

king1# nmap r2.simson.net
Starting nmap V. 2.54BETA34 ( www.insecure.org/nmap/ )
Interesting ports on r2.nitroba.com (64.7.15.234):
(The 1545 ports scanned but not shown below are in state: filtered)
Port       State       Service
22/tcp     open        ssh                     
25/tcp     open        smtp                    
53/tcp     open        domain                  
80/tcp     open        http                    
110/tcp    open        pop-3                   
389/tcp    open        ldap                    
443/tcp    open        https                   
465/tcp    open        smtps                   
554/tcp    closed      rtsp                    
993/tcp    open        imaps                   
995/tcp    open        pop3s                   

Nmap run completed -- 1 IP address (1 host up) scanned in 161 seconds
king1#

Alternatively, we can attempt to connect to these ports from a remote site using the telnet command:

% telnet r2.simson.net 1022
Trying 64.7.15.234...
telnet: connect to address 64.7.15.234: Operation timed out
telnet: Unable to connect to remote host
%

So it seems that the firewall is properly working. This is always a good thing to verify.

Limitation of netstat and lsof

There are many ways for a program to be listening for commands over the Internet without having the socket on which it is listening appear in the output of the netstat or lsof commands. Attackers have used all of these techniques to create programs that wait for an external trigger and, upon receipt of the trigger, carry out some predetermined action. These programs are typically called zombies.[175] They can be used for many nefarious purposes, such as carrying out remote denial-of-service attacks, erasing the files on the computer on which they are running, or even carrying out physical attacks (through the use of control equipment that may be connected to the computer).

Here are a few of the ways that a zombie might be triggered:

  • The zombie might join an Internet Relay Chat room. If a special password is typed in the room, that might be a signal to the zombie to attack a remote machine.

  • The zombie might periodically probe a web page or make a specific DNS request, and carry out an attack depending upon the response that it receives.

  • The zombie might listen to the raw Ethernet device in promiscuous mode and initiate an attack when a command is sent to another computer that is on the same local area network. To further confuse matters, the zombie might initiate its attack using packets that have forged source addresses so that they appear to come from the other computer, when in fact they do not.

  • The zombie might run inside the system’s kernel and be activated if an otherwise legitimate IP packet is received that has a particular IP or TCP option set. The trigger might be a sequence of values in the time-to-live field.

  • Instead of listening to the network, the zombie might instead probe the computer’s log files. The zombie might be activated if a particular URL is fetched from the web server, or if a particular firewall rule is exercised.

Any of the above triggers might be set up so that they work only if they are exercised at a particular time.

To complicate matters even further, your system’s kernel or utilities might be patched so that the process or TCP sockets associated with the zombie do not appear in program listings.

Monitoring Your Network with tcpdump

You can use the tcpdump command to watch packets as they move over your network. This command is included as a standard part of most Unix systems. The tcpdump command attaches to an interface and reads all the packets, optionally displaying them in your terminal window or writing them into a file. You can also specify a filter—either simple or complex—using the tcpdump filter language. ( Solaris systems come with a program called snoop that performs much the same function; you can also download a copy of tcpdump to run with Solaris systems.)

The tcpdump command has this syntax:

tcpdump [ -adeflnNOpqRStvxX ] [ -c count ] [ -F file ]
               [ -i interface ] [ -m module ] [ -r file ]
               [ -s snaplen ] [ -T type ] [ -w file ]
               [ -E algo:secret ] [ expression ]

Special options that you may care about include:

-i interface

Specifies the interface that tcpdump should listen to. The ifconfig -a command can be used to list all the interfaces on a system:

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:50:DA:21:EE:0E
          inet addr:10.15.9.3 Bcast:10.15.9.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4516220 errors:6 dropped:0 overruns:1 frame:8
          TX packets:1061622 errors:0 dropped:0 overruns:0 carrier:779
          collisions:30650 txqueuelen:100
          RX bytes:745434919 (710.9 Mb)  TX bytes:624301746 (595.3 Mb)
          Interrupt:11 Base address:0xc000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:233421 errors:0 dropped:0 overruns:0 frame:0
          TX packets:233421 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:52307549 (49.8 Mb)  TX bytes:52307549 (49.8 Mb)
-c count

Specifies the number of packets that should be recorded. By default, tcpdump runs until you type Ctrl-C.

-F file

Specifies a file that contains the filter to use

-s snaplen

Specifies the number of bytes of each packet that tcpdump should record. Normally, tcpdump records only the first 68 bytes of each packet. This is useful for traffic analysis, but is not useful if you are interested in viewing the contents of the packets. Specify -s 4096 to be sure that you are getting complete packets.

-w file

Specifies that tcpdump should write its packets to a file, rather than displaying them on the terminal.

-r file

Specifies that tcpdump should read packets from a file, rather than from the interface. This can be useful when analyzing dump files that have been previously created.

-n

Specifies that tcpdump should not convert IP addresses to hostnames. Normally, tcpdump performs a reverse name lookup on each IP address that it sees. Unfortunately, this can slow your system dramatically. It can also tell an attacker that you are monitoring the network.[176]

-v, -vv, -vvv, -vvvv

Prints increasingly verbose amounts of information.

The tcpdump command is a great tool for learning what is going over your network. It can also be a great tool for violating people’s privacy because people often send information over a network that is confidential, but without using encryption to ensure that it stays confidential. Remember that tcpdump captures packets moving over the network, whether or not they are originating or destined for your host. (Also remember that others on the network may also have access to tcpdump!)

Warning

Be aware that some local, state, and national laws may apply to the monitoring of network traffic. Wiretapping, email privacy laws, and even espionage statutes might come into play. Thus, if you intend to monitor network traffic, you should obtain the advice of competent legal counsel before doing so. Also note that your users may view excessive monitoring or storage of logs to be a serious invasion of privacy. Monitoring should be kept to a minimum, and you should ensure that your users understand that you are doing it—finding out by accident will do little to build trust and cooperation with your user population.

For example, to display the next 16 packets moving over a network, you might use this command:

r2# tcpdump -i dc0 -c 16
tcpdump: listening on dc0
18:20:32.992381 r2.ssh > sdsl-64-7-15-235.dsl.bos.megapath.net.3055: P 1386964717:
1386964761(44) ack 819912634 win 58400 (DF) [tos 0x10] 
18:20:32.993592 arp who-has r2 tell sdsl-64-7-15-235.dsl.bos.megapath.net
18:20:32.993630 arp reply r2 is-at 0:3:6d:14:f1:c7
18:20:32.994151 sdsl-64-7-15-235.dsl.bos.megapath.net.3055 > r2.ssh: . ack 44 win 
63588 (DF)
18:20:33.012035 r2.1561 > 209.67.252.198.domain:  17877 PTR? 204.130.200.216.in-addr.
arpa. (46)
18:20:33.127273 ipc3798c16.dial.wxs.nl.netview-aix-7 > r2.http: . ack 3791268234 win 
8576 (DF)
18:20:33.127448 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 7505:8041(536) ack 
0 win 57352 (DF)
18:20:33.127494 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 8041:8577(536) ack 
0 win 57352 (DF)
18:20:33.294095 ipc3798c16.dial.wxs.nl.netview-aix-7 > r2.http: . ack 1073 win 8576 
(DF)
18:20:33.294257 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 8577:9113(536) ack 
0 win 57352 (DF)
18:20:33.294298 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 9113:9649(536) ack 
0 win 57352 (DF)
18:20:33.490989 ipc3798c16.dial.wxs.nl.netview-aix-7 > r2.http: . ack 2145 win 8576 
(DF)
18:20:33.491092 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 9649:10185(536) ack 
0 win 57352 (DF)
18:20:33.491125 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 10185:10721(536) ack
0 win 57352 (DF)
18:20:33.637745 hoh.centurytel.net.36672 > sdsl-64-7-15-236.dsl.bos.megapath.net.
domain:  51006 [1au] AAAA? www.yoga.com. OPT  UDPsize=4096 (41) (DF)
18:20:33.638473 hoh.centurytel.net.36672 > sdsl-64-7-15-236.dsl.bos.megapath.net.
domain:  40001 [1au] A6 ? www.yoga.com. OPT  UDPsize=4096 (41) (DF)
r2#

Apparently, there are several hosts on this network. Two of them are running web servers. If you wish to see only packets that are requesting web pages, you could run tcpdump with a filter:

r2# tcpdump -i dc0 -c 10 dst port 80
tcpdump: listening on dc0
18:25:25.888628 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: P 
4030704166:4030704548(382) ack 3582479098 win 65535 <nop,nop,timestamp 13952175 
419395>
18:25:25.952951 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: . 
ack 2897 win 64252 <nop,nop,timestamp 13952175 419495>
18:25:25.977404 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: . 
ack 5793 win 64252 <nop,nop,timestamp 13952176 419495>
18:25:26.158506 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: . 
ack 6475 win 65535 <nop,nop,timestamp 13952176 419495>
18:25:28.679752 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: P 
382:765(383) ack 6475 win 65535 <nop,nop,timestamp 13952181 419495>
18:25:28.743668 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: . 
ack 9371 win 64252 <nop,nop,timestamp 13952181 419523>
18:25:28.767757 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: . 
ack 12267 win 64252 <nop,nop,timestamp 13952181 419523>
18:25:28.785001 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: . 
ack 14411 win 65004 <nop,nop,timestamp 13952181 419523>
18:25:40.627919 200-158-162-37.dsl.telesp.net.br.4711 > sdsl-64-7-15-236.dsl.bos.
megapath.net.http: F 1600587054:1600587054(0) ack 3610767708 win 64499 (DF)
18:25:40.800037 200-158-162-37.dsl.telesp.net.br.4711 > sdsl-64-7-15-236.dsl.bos.
megapath.net.http: . ack 2 win 64499 (DF)

If you want to see what the remote users are actually sending, you can save the packets into a file (remembering to tell tcpdump to record the entire packet) and then use the strings command:

r2# tcpdump -i dc0 -c 16 -s 4096 -w packets.dmp dst port 80
tcpdump: listening on dc0
r2# strings packets.dmp 
(F9@
(G9@
A=q)
(H9@
(I9@GET /roots/menu/default.asp HTTP/1.1
Accept: */*
Referer: http://www.yoga.com/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
Host: www.yoga.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDGGGQGCJU=DKDBOMMABEJIHPAGBANHCHKA
(J9@
(K9@
(L9@
Q#RP
Q#RP
" -z
GET /home.asp HTTP/1.1
Accept: */*
Referer: http://www.yoga.com/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
Host: www.yoga.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDGGGQGCJU=DKDBOMMABEJIHPAGBANHCHKA
(M9@
NN      P
" 79
r2#

Significantly more sophisticated analysis can be performed using snort, an open source intrusion detection system, or using a commercial network forensics analysis tool, which will monitor all of the traffic that passes over the network, reassemble the TCP/IP streams, and then analyze the data. Systems like these not only monitor packets, but also analyze them and compare them to rules designed to detect intrusion attempts. For example, here’s some of the output of snort:

Aug 20 14:07:33 tala snort[24038]: [1:615:3] SCAN SOCKS Proxy attempt 
[Classification: Attempted Information Leak] [Priority: 2]: {TCP} 128.171.143.7:2436 
-> 10.13.6.226:1080
Aug 20 14:12:55 tala snort[24038]: [1:1734:4] FTP USER overflow attempt 
[Classification: Attempted Administrator Privilege Gain] [Priority: 1]: {TCP} 62.64.
166.237:3158 -> 10.13.6.226:21
Aug 20 14:23:19 tala snort[24038]: [1:884:6] WEB-CGI formmail access [Classification:  
sid] [Priority: 2]: {TCP} 162.83.207.174:2129 -> 10.13.6.226:80
Aug 20 14:44:46 tala snort[24038]: [1:654:5] SMTP RCPT TO overflow [Classification: 
Attempted Administrator Privilege Gain] [Priority: 1]: {TCP} 128.248.155.51:44743 -> 
10.13.6.226:25
Aug 20 15:07:48 tala snort[24038]: [1:937:6] WEB-FRONTPAGE _vti_rpc access 
[Classification:  sid] [Priority: 2]: {TCP} 202.155.89.77:2566 -> 10.13.6.226:80

This log shows several intrusion attempts on the host 10.13.6.226, including a scan for an open SOCKS proxy (which can be abused by spammers), an attempt to overflow the FTP server’s buffer with a long USER command, an attempt to access the formmail CGI script (which has been abused by spammers), an attempt to overflow the SMTP server’s buffer with a long RCPT TO command, and an attempt to access one of the private directories used by web sites managed with Microsoft FrontPage.

Network Scanning

In recent years, a growing number of programs have been distributed that you can use to scan your network for known problems. Unfortunately, attackers can also use these tools to scan your network for vulnerabilities. Thus, you would be wise to get one or more of these tools and try them yourself, before your opponents do.

There are several kinds of network scanners available today:

Commercial network scanners

These programs, typified by the Internet Security Scanner (ISS), systematically probe all of the ports of every host on your network. When a TCP connection is accepted, the scanner examines the resulting banner and looks in its database to see if the banner corresponds to a version with known security vulnerabilities. The advantage of these systems is their large database of vulnerabilities. The disadvantage of these systems is that they are frequently licensed to scan a limited set of IP addresses, and those licenses can be quite expensive.

Freeware security scanners

These programs are similar to commercial scanners, except that they are usually open source tools that are freely available. An early example of such a program was SATAN; a popular and up-to-date one is Nessus. The advantage of these systems is their cost. The disadvantage is that their databases can be limited when compared to the commercial offerings, though Nessus in particular has a very extensive database.

Security Scanners

Before 1990, people didn’t like to talk about security vulnerabilities. It was difficult to find published papers describing vulnerabilities: how they came to be, how they were found, and how to fix them. To find out about problems one had to get a “friend of a friend” introduction to one of the closed mailing lists, or else get a copy of a closely guarded technical report detailing problems. The result was that most system administrators didn’t know how to secure their systems, and researchers couldn’t perform organized studies of vulnerabilities.

That changed when Dan Farmer wrote the COPS scanner under the direction of Gene Spafford at Purdue, then released it on the Usenet. Suddenly, there was a widely available system that scanned for vulnerabilities that were known to several experts and also gave recommendations on how to patch them. (It was an explicit design principle of the project to provide information about how to fix the problems rather than exploit them.)

COPS has been downloaded, modified, used, extended, emulated, and studied by hundreds of thousands of people in the intervening years. It succeeded in many ways beyond the authors’ expectations. However, there are at least two sets of thoughts that we pose from this experience that are interesting to contemplate:

  • As recently as early 2002, Spafford is still getting requests for help with configuring COPS and interpreting the output! The software is 12 years old. What does it say about sysadmins that they still expect this software to work? What does it say about the coding and design used that parts of COPS still do work? What does it say about coding practices that many versions of Unix and Linux are still shipped with vulnerabilities that COPS identifies?

  • Had Farmer and Spafford taken out software patents on the scanner and some of its subsystems, the patents would still be in force and the authors might be very wealthy. However, would the overall state of security on the Internet be better today as a result? Would there be fewer security tools developed and in use? Maybe people would be less tolerant of flaws in deployed systems if scanning tools were less available? (Contrast this with what patents on public-key cryptography did to security.) Does this imply anything about software patents?

As with most other aspects of Internet technology, it is amazing to see how much has changed in only 10 or 15 years. And to think what the next decade will bring.

Freeware port scanners

These programs typically scan for open ports and services, but they do not include a database of known vulnerabilities. One example of these programs is nmap, the network mapper, which can perform a large number of different kinds of scans and is also remarkably good at identifying the operating system of a remote machine based on the way it responds to scanning. A typical output from nmap was shown earlier, in Section 12.4.1.


[170] Typically, mirror or monitor ports can be created on managed switches, but cannot be created on low-cost switches.

[171] RFC 793 defines the TCP states, in case you’re interested. TIME_WAIT means that the local process is “waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.”

[172] lsof stands for “list open files”—on Unix systems, network connections, like nearly everything else, can be treated as a kind of file. It’s available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/. If it’s distributed with your operating system, make sure that nonprivileged users can’t use it to see files and devices owned by other users; if they can, rebuild it from the source code.

[173] Of course, we don’t know about the unknown problems!

[174] nmap is a powerful port scanner that is distributed with many Unix operating systems, or available from http://www.insecure.org/nmap.

[175] Not to be confused with defunct processes, which are listed by the ps command as type “Z” (zombie). Defunct processes are usually the result of sloppy programming or unusual system events, but don’t usually represent a security concern in and of themselves.

[176] An attacker can send packets to a nonexistent host with a source IP address that is not used for any other purpose. If a reverse DNS query is performed for that IP address, the attacker knows that somebody is sniffing the traffic on the network.