Comparing Classic Intrusion Detection Test Data against Data Found in
the Wild

Matthew Morgan and Scott Campbell

Office of Science, SULI Program

University of Tulsa

Lawrence Berkeley National Laboratory

Berkeley, California

August 13, 2003

Prepared in partial fulfillment of the requirements of the Office of
Science, DOE Student Undergraduate Laboratory Internship (SULI) Program
under the direction of Howard Walter and Scott Campbell in the National
Energy Research Scientific Computing Division of the Ernest Orlando
Lawrence Berkeley National Laboratory.

Participant:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Signature

Research Advisor:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Signature

# ABSTRACT

Comparing Classic Intrusion Detection Test Data against Data Found in
the Wild. MATTHEW MORGAN (University of Tulsa, Tulsa, OK 74104) SCOTT
CAMPBELL (Lawrence Berkeley National Laboratory, Berkeley, California
94720)

With the impromptu development and heterogeneity of today\'s Internet,
things don\'t always go as planned. Real-world Internet traffic exhibits
far more variation than is generally appreciated by the application
development community.  Poorly configured routers, faulty software and
many other factors can maim packets, destroying the information they
contain and confusing the applications that receive them. Unfortunately,
network security applications are no exception; intrusion detection
systems (IDSs) developed and tested in controlled environments tend to
misbehave when exposed to unregulated traffic on the Internet. This
paper will compare inconsistencies in network traffic protocols between
synthetic and raw Internet data using the Bro intrusion

detection system.  Differences between \'classic\' synthetic data and
\'raw\' Internet traffic will be enumerated and used to explain why
applications tested only with synthetic data tend to fail when placed in
the real world.

# Table of Contents

Title Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 3

1\. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 4

2\. Traffic Generation . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 4

2.1. Methods of Generating Traffic . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 5

2.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 5

3\. Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1. An Example Intrusion Detection System: Bro . . . . . . . . . . . .
. . . . . . . . . . . . 6

4\. Comparing Test Data versus Real Data Using Bro Output . . . . . . .
. . . . . . . . . . . 6

4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 7

4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2.1. TCP Events . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 9

4.2.2. DNS Events . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 10

4.2.3. HTTP Events . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 10

4.2.4. IP Fragmentation Events . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 11

5\. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 12

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 12

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 14

**1. INTRODUCTION**

With the volume of traffic that flows through a network at any given
time, constant human surveillance of the network for hostile activity is
impractical for smaller networks and virtually impossible for larger
networks. How can an organization tell when they\'re being attacked?
Installing an Intrusion Detection System (IDS) is the best way for an
organization to detect, and possibly prevent, network intrusions.

Because of the importance of IDSs in maintaining secure networks, proper
testing must be conducted to ensure that: A) the system is highly
efficient at recognizing attacks, and B) the system produces a minimal
number of false-positives \[1\]. The testing of these areas is a topic
of much research \[2,3,4\], which is often based on "classical"
synthetic data (herein referred to as test data) and/or limited network
exposure. This paper will investigate the differences between the use of
test data and raw Internet traffic (herein referred to as real data) by
comparing the output of the Bro IDS \[5,6\]. The goal of this test is to
provide other researchers with a clear indication of the differences
between real and test data.

**2. TRAFFIC GENERATION**

As this paper deals with the inherent problems of using test data as a
substitute for real data, a basic understanding of how traffic
generation works is necessary to fully appreciate the findings of this
research. This section will show the methods used in generating test
data (using the 1999 Lincoln Labs corpus as an example \[2\]), and\
discuss the shortcomings of using such data in testing intrusion
detection systems.

1.  **METHODS OF GENERATING TRAFFIC**

There are two rudimentary methods of deriving traffic: automata and
\"actors.\" Automata are programs designed to perform a specific
function. In the case of Lincoln Labs\' corpus, automata were designed
to perform duties characteristic of a certain type of user. Programmer
automata edited and compiled C programs, read UNIX man pages, and ran\
programs. Secretaries edited documents and sent email. Common users
read/sent email and browsed the Web. Not only were the automata able to
express the functionality of a specific type of user, they could also
convey the behavior of such users by using statistical profiles to
determine the frequency and variety of commands issued, login times,
session durations, and much more. The "actors" performed the more
complex tasks such as upgrading software, adding users, changing
passwords, and remotely accessing programs within the controlled
environment.

2.  **PROBLEMS WITH GENERATING TRAFFIC**

Although great care was taken to ensure the legitimate background
traffic was comparable to that of an actual network, there is little
evidence that illegitimate traffic, often referred to as Internet
\"crud\", was considered or introduced. This "crud" consists of all the
things you shouldn\'t see on a network but often do \[5,7,8,9\]. Poorly
implemented network protocols, bug-ridden software, and faulty hardware
can mangle packets in ways that can give them a malicious appearance.
Even though these types of packets are not usually created intentionally
(except possibly to exercise a security

vulnerability), they do exist as a sort of \'background radiation\' in
the real- world, and researchers must account for them when attempting
to simulate the Internet.

**3. INTRUSION DETECTION**

An intrusion detection system is a vital component of any network
security architecture. Because administrators can't watch every bit of
traffic that passes through their network, intrusion detection systems
monitor traffic as it passes certain points and alert the administrators
(be it in real-time or logs) when possibly malicious activity is
noticed. Malicious activity can be identified by traffic anomalous to
what is normal for that particular network or from traffic signatures
characteristic of known attacks. While being able to detect malicious
activity is vital, intrusion detection systems should not flag benign
traffic as attacks. A frequent false-positive rate can cause
administrators to ignore the system, leaving legitimate alerts
unnoticed.

1.  **AN EXAMPLE INTRUSION DETECTION SYSTEM: BRO**

Bro is a stand-alone IDS capable of detecting attacks in real-time and
conducting detailed network analysis. Because the system was designed to
deal with high-speed networks, Bro avoids obstructing the flow of
traffic by passively "listening" to traffic rather than acting as a
filter. This system is employed by the National Energy Research
Computing (NERSC) Center as an operational intrusion detection and
network analysis mechanism, and served as the processing unit for this
experiment.

3.  **COMPARING TEST DATA VS. REAL DATA USING BRO OUTPUT**

In order to quantify the difference between test data and real data, the
test data must be subjected to a real-world IDS so that the output may
be compared to day-to-day Internet activity of the network. This section
will describe the methods used to produce comparable data and an
analysis of the results.

**4.1. METHODS**

BRO produces many log files as it monitors traffic. This study is
primarily concerned with A) logs that give an overview of every
connection (red files), and B) logs that serve as a record for packets
exhibiting unusual behavior (weird files). The red files contain a
reduced summary of the connections for all traffic Bro sees while
running.  The fields contained within are as follows: \<start\>
\<duration\> \<originator bytes\>

\<responder bytes\> \<service\> \<originating IP\> \<originating port\>
\<destination IP\> \<destination port\> \<state\> \<flags\> \<addl\>.
Each of these fields is explained in detail in the generic connection
analysis section of \[6\].

The weird files are a result of anomalous packet or protocol behavior.
Every time Bro comes across a packet exhibiting abnormal
characteristics, it creates an entry the weird file and records the
appropriate information. A list of common weird file event types is
explained the weird module section of \[6\]. The combination of these
two log files gives the security administrator the ability to
investigate an event, IP address, connection, and many other aspects of
the traffic flowing through Bro.

Because the red files are based on connections rather than individual
packets, the percentages in Tables 1-4 represent the frequency of such
events per total connections enumerated in Table 5. Even though the test
data is split into subsets corresponding to the days on which the data
was processed, this method is preferred to a time-based measurement
(i.e. 60-minutes of network traffic), because a time-based comparison
would not account for a difference in bandwidth between NERSC and the
network where the test data originated.

The 1999 DARPA Intrusion Detection off-line evaluation consisted of
three weeks of training data and two weeks of testing data. The training
data was provided to allow anomaly-based IDSs to develop a foundation
for what is normal activity and what is unusual. The first and third
weeks contained no attack data in order to provide\
examples of normal traffic, while the second week allowed the systems to
observe what conditions should spawn an alert. The testing data of the
fourth and fifth weeks contained a mix of attacks and background
traffic, which was used to produce the results of the evaluation. Each
day of testing contained inside data representing local traffic, and
outside data containing local and non-local traffic. As this study deals
with the quality of the Internet-based data, the inside data sets were
excluded. The outside data was split into attack data (weeks 2, 4, and
5), and attack-free data (weeks 1 and 3) in order to differentiate
between weird events from an attack and those caused by Internet
"crud".\
Even though the preservation of the test data is important to the
validity of this study, filters were applied using tcpdump \[10\]. ICMP
traffic was removed, because Bro was not able to properly analyze such
packets. Also, non-IP-based traffic was removed to eliminate traffic
produced by proprietary protocols reflective of the originating
network's infrastructure, such as the Cisco Discovery Protocol (CDP).
Finally, raw Ethernet frames were removed in order to focus the study on
non-local traffic.\
Results were taken for three groups to provide the comparison: Lincoln
Labs attack-free test data, Lincoln Labs mixed test data, and NERSC
mixed real data. Because the data collected from NERSC represents
traffic a typical network experiences in normal operation, attack-free
real data is unattainable. The results were categorized based on the
area in which the weird event occurred: TCP, DNS, IP Fragmentation and
HTTP.

2.  **ANALYSIS**

The following subsections give an interpretation of the results, and
provide examples from each category of a weird event that can confuse an
IDS into inappropriately signaling an attack.

**4.2.1 TCP EVENTS**

Particular attention was paid to the TCP events collected in this
research, because its complexity makes it prone to improper
implementation. This makes it a prime target for attacks as well as a
good source of Internet "crud". Also, many types of scans use a variety
of flags in looking for open ports. Unsolicited_SYN_response events are
signaled by Bro when it receives a packet referencing a connection it
does not show as being established. Because TCP is a connection-oriented
protocol, application data is not allowed until a connection is
established via a process known as the TCP handshake. Therefore, if the
first packet in a TCP connection is anything except for a SYN, this
condition is met. The large number of unsolicited_SYN_response events in
the NERSC data is an expected occurrence, because Bro is periodically
shut down and restarted in order to flush the system. When Bro starts
back up, it has no records of the TCP connections already established,
and, therefore, considers every packet it receives of a previously
operational connection as unsolicited.

The TCP section appears to be the only section where weird entries are
found for the attack-free data. (This excludes the HTTP data of Table 3,
which is partially anomalous and will be describe in more detail later.)
However, this is not necessarily indicative of the addition of broken
connections (a.k.a Internet \"crud\") into the attack-free data, but
more likely a sign of packets arriving out of sequence. The particular
events triggered in the attack-free data help to further this point. For
example, the data_before_established event is often caused by data being
sent before the TCP handshake, mentioned above, has completed.

2.  **DNS EVENTS**

The attack-free test data contains no weird entries for DNS traffic;
however, the mixed test data contains a small number of entries that
serve as an indication of a DNS-based attack. Although there is no
quantification of how many of the NERSC events are contributed by actual
attacks, there is a substantial difference in the volume and type of
events in the two sets of mixed data. The lack of unusual DNS content,
irrespective of the contribution of NERSC events from attacks, shows the
inability of the methods used to produce the test data to adequately
represent true Internet behavior.

3.  **HTTP**

As indicated earlier, the data collected for the unmatched_HTTP_reply
and HTTP_version_mismatch events appears to contain anomalies that
required further attention. Due to the surprisingly high numbers, the
data was run through the system a second time for clarification. After
the results of the second test returned identical to that shown in Table
3, a sample HTTP session (included in appendix B) was extracted using
tcpdump and manually reviewed for abnormalities. Verification of several
connections showed no signs of errors in the connection mechanics
indicating a malfunction within the analysis system itself.

Other than the anomalous data, the number of HTTP weird events found
within both the attack-free and mixed test data seem to match the number
of events found within the real data. Therefore, the HTTP test data
appears to give an adequate simulation of real HTTP traffic.

4.  **IP FRAGMENTATION EVENTS**

IP fragmentation is a common event with Internet traffic. It occurs when
large IP packets are broken up into smaller ones allowing the pieces to
traverse links of smaller MTU size. Although this is a much-needed
service, it introduces a new avenue for exploitation and obfuscation.
Many attacks involving IP fragmentation aim to either A) cause a
Denial-of-Service (DoS) by sending a series of packets that exhaust a
system's resources or exploit flaws in the systems IP stack, or B)
bypass security measures that do not perform, or inadequately perform,
packet reassembly. The fragment_overlap event is a prime example of the
latter. By making the ends of packet fragments overlap, an attacker can
make a series of seemingly harmless smaller packets form an attack once
assembled. The number of entries in this category for the mixed test
data shows the signs of such an attack; however, the lack of such events
in the real data questions the emphasis the test data puts on the
detection of this type of attack rather than one found more prevalent n
the real data.

4.  **CONCLUSIONS**

Proper testing of intrusion detection systems is necessary in order to
facilitate improved design by providing useful feedback and ensure the
system will perform in a predictable manner when employed in a
real-world situation. While the 1999 DARPA intrusion detection
evaluations served as a foundation for testing intrusion detection
systems, the use of synthetic data may have favored systems that perform
well in academic environments, but not necessarily in the wild. If
synthetic traffic is to continue to be used in evaluations such as
these, it must include all of the characteristics of the Internet,
including the imperfections, in order to ensure a clean transition of a
system from an academic environment to the real world.

# ACKNOWLEDGEMENTS

The authors would like to thank the following people and groups who
helped make this paper possible: The Department of Energy, Lawrence
Berkeley National Laboratory, the National Energy Scientific Computing
Center, Howard Walter and the Networking and Cyber-security group,
Laurel Egenberger, Susan Aberg, Robert Wellbrock, Gary Buckmaster,
Robert Lovelady, and Christopher Rickert.

The research described here was performed at the Lawrence Berkeley
National Laboratory and funded by the Department of Energy Office of
Science under Contract No. DE-AC03-76SF00098.

# REFERENCES

\[1\] McHugh, J. ,"Testing Intrusion Detection Systems: A Critique of
the 1998 and 1999 DARPA Intrusion Detection System Evaluations as
Performed by Lincoln Laboratory", *ACM Transactions on Information and
System Security*, 3(4), Association for Computing Machinery, New York,
NY, Nov. 2000, pp. 262-294.

\[2\] Lippman, R.P., Haines, J.W., Fried, D.J., Korba, J., Das, K. ,"The
1999 DARPA Off-Line Intrusion Detection Evaluation", *Proceedings of the
Third International Workshop on the Recent Advances in Intrusion
Detection: Lecture Notes in Computer Science series,* Springer Verlag*,*
Toulouse, France, Oct. 2000.

\[5\] Paxson, V. ,"Bro: A System for Detecting Network Intruders in
Real-Time", *Computer Networks,* 31(23-24), Elsevier Inc., San Diego,
California, Dec. 1999, pp. 2435-2463.

\[6\] Paxson, V. , The *Bro* 0.8 User Manual,
http://www.icir.org/vern/bro-manual/, ICSI Center for Internet Research,
Berkeley, California, Nov. 2002.

\[7\] Bykova, M. ,"Statistical Analysis of Malformed Packets and Their
Orgins in the Modern Internet", *Master's Thesis*,
http://irg.cs.ohiou.edu/papers, Mar. 2002.

\[8\] Bellovin, S.M. ,"Packets Found on an Internet", *Computer
Communications Review* 23(3), Association of Computing Machinery, July
1993.

\[9\] Floyd, S., Paxson, V. ,"Difficulties in Simulating the Internet",
*IEEE/ACM Transactions on Networking,* 9(4), Institute of Electrical and
Electronic Engineers/Association of Computing Machinery, Aug. 2001, pp.
392-403.

\[10\] Jacobson, V., Leres, C., McCanne, S.D., tcpdump,
http://www.tcpdump.org, Jun. 1989.

# 

# Appendix A: Event Tables

*Table 1: TCP Events*

  -------------------------------- ---------- ------------- ------------- --------- ------------- --------- -------------
                                              Lincoln Labs                                        NERSC     

                                              Attack-free                 Mixed                   Mixed     
                                              Data                        Data                    Data      

  Event                            Category   Entries       \% of total   Entries   \% of total   Entries   \% of total
                                                            connections             connections             connections

                                                                                                            

  Unsolicited_SYN_response         TCP        12            0.002%        47        0.005%        1537582   1.907%

  spontaneous_RST                  TCP                      0.000%        939       0.098%        1069119   1.326%

  connection_originator_SYN_ack    TCP                      0.000%        4         0.000%        836593    1.038%

  RST_with_data                    TCP                      0.000%                  0.000%        565450    0.701%

  SYN_seq_jump                     TCP                      0.000%        1         0.000%        232202    0.288%

  Data_before_established          TCP        2             0.000%        29        0.003%        146010    0.181%

  active_connection_reuse          TCP        76            0.011%        167       0.017%        98440     0.122%

  possible_split_routing           TCP        2             0.000%        28        0.003%        32129     0.040%

  bad_TCP_checksum                 TCP                      0.000%        12        0.001%        28442     0.035%

  spontaneous_FIN                  TCP                      0.000%        1167      0.122%        19350     0.024%

  line_terminated_with_single_CR   TCP        1949          0.293%        2537      0.264%        8952      0.011%

  window_recision                  TCP        5             0.001%        3         0.000%        4841      0.006%

  truncated_header                 TCP                      0.000%                  0.000%        101       0.000%

  SYN_after_reset                  TCP                      0.000%        5         0.001%        58        0.000%

  bad_SYN_ack                      TCP                      0.000%                  0.000%        48        0.000%

  bad_TCP_header_len               TCP                      0.000%                  0.000%        47        0.000%

  NUL_in_line                      TCP                      0.000%        1         0.000%        29        0.000%

  FIN_advanced_last_seq            TCP        9             0.001%        421       0.044%        22        0.000%

  TCP_Christmas                    TCP                      0.000%                  0.000%        16        0.000%

  inappropriate_FIN                TCP                      0.000%                  0.000%        130       0.000%

  SYN_inside_connection            TCP                      0.000%                  0.000%        118       0.000%

  premature_connection_reuse       TCP                      0.000%                  0.000%        76        0.000%

  FIN_after_reset                  TCP                      0.000%        85        0.009%        348       0.000%

  SYN_after_close                  TCP                      0.000%                  0.000%        1594      0.002%

  Data_after_reset                 TCP                      0.000%        16        0.002%        1272      0.002%
  -------------------------------- ---------- ------------- ------------- --------- ------------- --------- -------------

*Table 2: DNS Events*

  -------------------------------- ---------- ------------- ------------- --------- ------------- --------- -------------
                                              Lincoln Labs                                        NERSC     

                                              Attack-free                 Mixed                   Mixed     
                                              Data                        Data                    Data      

  Event                            Category   Entries       \% of total   Entries   \% of total   Entries   \% of total
                                                            connections             connections             connections

                                                                                                            

                                                                                                            

  DNS_truncated_label              DNS                      0.000%        2         0.000%        80        0.000%

  DNS_name_too_long                DNS                      0.000%        2         0.000%        38        0.000%

  DNS_label_too_long               DNS                      0.000%        2         0.000%        76        0.000%

  forward_DNS_compression_offset   DNS                      0.000%                  0.000%        76        0.000%

  Bad_DNS_RR_length                DNS                      0.000%        3         0.000%        8         0.000%

  unknown_DNS_RR_type              DNS                      0.000%                  0.000%        26794     0.033%

  truncated_DNS_RR                 DNS                      0.000%                  0.000%        7626      0.009%

  DNS_RR_length_mismatch           DNS                      0.000%                  0.000%        7568      0.009%

  truncated_DNS                    DNS                      0.000%        8         0.001%        209       0.000%
  -------------------------------- ---------- ------------- ------------- --------- ------------- --------- -------------

*Table 3: HTTP Events*

  ---------------------------- ---------- ------------- ------------- --------- ------------- --------- -------------
                                          Lincoln Labs                                        NERSC     

                                          Attack-free                 Mixed                   Mixed     
                                          Data                        Data                    Data      

  Event                        Category   Entries       \% of total   Entries   \% of total   Entries   \% of total
                                                        connections             connections             connections

                                                                                                        

  illegal\_%\_at_end_of_URI    HTTP                     0.000%                  0.000%        10        0.000%

  unescaped\_%\_in_URI         HTTP       12            0.002%        13        0.001%        288       0.000%

  unmatched_HTTP_reply         HTTP       306742        46.153%       424212    44.169%       4417      0.005%

  unescaped_special_URI_char   HTTP       2874          0.432%        4008      0.417%        3331      0.004%

  HTTP_version_mismatch        HTTP       28247         4.250%        40753     4.243%        728       0.001%

  double\_%\_in_URI            HTTP                     0.000%                  0.000%        81        0.000%
  ---------------------------- ---------- ------------- ------------- --------- ------------- --------- -------------

*Table 4: IP Fragmentation Events*

  ----------------------------- ---------- ------------- ------------- --------- ------------- --------- -------------
                                           Lincoln Labs                                        NERSC     

                                           Attack-free                 Mixed                   Mixed     
                                           Data                        Data                    Data      

  Event                         Category   Entries       \% of total   Entries   \% of total   Entries   \% of total
                                                         connections             connections             connections

                                                                                                         

  fragment_overlap              Frag                     0.000%        217       0.023%                  0.000%

  fragment_size_inconsistency   Frag                     0.000%        2         0.000%        14        0.000%

  fragment_with_DF              Frag                     0.000%                  0.000%        233       0.000%

  fragment_inconsistency        Frag                     0.000%        55        0.006%        194       0.000%

  excessively_small_fragment    Frag                     0.000%        2944      0.307%        478       0.001%

  excessively_large_fragment    Frag                     0.000%                  0.000%        451       0.001%
  ----------------------------- ---------- ------------- ------------- --------- ------------- --------- -------------

*Table 5: Total Connections*

  ----------------------- ------------------ ------------ ----------------
                          Lincoln Labs                    NERSC

                          Attack-free Data   Mixed Data   Mixed Data

  Total Connections       664616             960424       80632283
  ----------------------- ------------------ ------------ ----------------

**Appendix B: HTTP tcpdump output**

> \% tcpdump -r tcpdump.wk1.mon.out -n\
> 06:14:50.782036 172.16.116.201.1774 \> 209.67.29.11.80: S\
> 3073954945:3073954945(0) win 512 \<mss 1460\>\
> 06:14:50.786584 209.67.29.11.80 \> 172.16.116.201.1774: S\
> 808279779:808279779(0) ack 3073954946 win 32736 \<mss 1460\>\
> 06:14:50.787244 172.16.116.201.1774 \> 209.67.29.11.80: . ack 1 win
> 32120 (DF)\
> 06:14:50.787917 172.16.116.201.1774 \> 209.67.29.11.80: P 1:205(204)
> ack 1 win 32120 (DF)\
> 06:14:50.804621 209.67.29.11.80 \> 172.16.116.201.1774: . ack 205 win
> 32736 (DF)\
> 06:14:50.806159 209.67.29.11.80 \> 172.16.116.201.1774: P 1:789(788)
> ack 205 win 32736 (DF)\
> 06:14:50.806273 209.67.29.11.80 \> 172.16.116.201.1774: F 789:789(0)
> ack 205 win 32736\
> 06:14:50.807479 172.16.116.201.1774 \> 209.67.29.11.80: . ack 790 win
> 31331 (DF)\
> 06:14:50.808455 172.16.116.201.1774 \> 209.67.29.11.80: F 205:205(0)
> ack 790 win 32120\
> 06:14:50.812213 209.67.29.11.80 \> 172.16.116.201.1774: . ack 206 win
> 32735 (DF)