[an error occurred while processing this directive]

<div id="intro">

<div id="pageHeader">
<h1>Final Project Archive</h1>
</div>

<div id="quickSummary"><p>
Know your network.
<p>
Know the Internet.
<p>
Know how they work together.
<p>
</div>


<div id="preamble"><p>
These are the final projects submitted by previous classes.
</div>

</div><!-- end intro -->
<h2>Fall 2009</h2>
<b>Assignment.</b>
For the final project, you will again be using the MAWI Sample Point F
data set.  The flow data resides in the class AFS directory on Andrew at
ssh://unix.andrew.cmu.edu/afs/andrew/course/95/855/*.rw.  This data was
collected at sample point F during the Day-In-The-Life-Of-The-Internet
exercise in 2009, as described at <a
href=http://tracer.csl.sony.co.jp/mawi/>
http://tracer.csl.sony.co.jp/mawi/ </a>. Be
sure you understand the anonymization scheme and the privacy guidelines
for using this data set.
<ol>
  <li>
      Briefly survey the data and select a class B (/16) network CIDR block
      for analysis.  The chosen block (.your network.) must have enough
      traffic to support analysis, but should not have so much traffic that
      analysis becomes overwhelming.
  </li><li>
      Profile your network.  Identify the key resources produced and
      consumed by the network, significant choke points, dependencies or other
      features presented in the data.
  </li><li>
      Your profile should lead to assumptions about how the network is
      constructed.  Based on this profile, make one or more architecture
      recommendations on how to improve the network.  This may include
      security, availability or policy improvements.
  </li><li>
      Select a recent internet-wide security event similar to those we have
      discussed in class.  Briefly present the event, and show how this event
      would impact your network and manifest itself in your data set.
  </li>
</ol>

Final Submissions:
<ul>
  <li>
      <a href=papers/final-a.pdf>
      Analysis of 8.76.0.0/16 in the MAWI data set
      </a><br/>
      Phil Burdette, Ryan Easton, Zack Loether, Derrick Spooner
      <br><i>
      The class B subnet that we analyzed was 8.76.0.0/16. During the course
      of the data collection period, this net block saw 25,457 unique
      traffic flows composed of 384,211 individual packets. This particular
      class B network was chosen for analysis over the others because of its
      size. It is large enough the provide interesting analysis points
      without being so huge that there would be too much data to
      analyze. Based upon the analysis conducted, we have come to the
      conclusion that this net block is probably entirely, or at least
      largely comprised of a corporate network. Some of our key findings
      included SMB scanning and possible worm infection. This was evident by
      performing flow analysis on the data packets that were captured. For
      an event analysis, we compared out net block.s activity to a DDoS
      attack of a Belarusian news site. A similar attack on our network
      would be extremely noticeable do to the significant increase in web
      traffic to our web servers. 
      </i>
      <br>
  </li><li>

      <a href=papers/final-b.pdf>
      Analysis of 193.52.0.0 and the MAWI set
      </a><br/>
      Ron Bandes,
      Francis Fbgormittah,
      Robert Jackson Lee,
      Allison MacFarlan
      <br><i>
      Political, environmental and network unrest were prevalent in the
      world on March 30th and 31st 2009. The primary concern in the
      information technology world was a worm called .Conficker. that
      had morphed two previous times and whose purpose and source code
      was still being extensively analyzed. There was general fear that
      on April 1st Conficker would expand its influence and release a
      nefarious payload or a destructive attack on the world.s networks.
      <p>
      Because of the time of our sample and the global focus on
      Conficker, we used this circumstance as the internet-wide
      .event. for our case study, and analyzed all the data in our
      sample to determine if Conficker had a significant effect on the
      large Class B network we chose for analysis (193.52.x.x). This was
      the problem we were trying to solve:
      <b>Was Conficker exhibited on our network, and if so, could we prove it?</b>
      </i>
      <br>
  </li><li>
  
      <a href=papers/final-c.pdf>
      Network Situational Awareness
      Group Project Report
      </a><br/>
      Chanon Sinitskul, Napat Ratanasirintrawoot, Will Zickefoose
      <br><i>
      In order to make an architecture improvement to the class B
      network block of 173.94.00/16, a one-day traffic flows data has
      been analyzed to profile the network. The dataset used for the
      analysis was captured from a trans-Pacific transit point from
      March 30, 2009 3pm to March 31, 2009 3pm.
      <p>
      The profiling shows that the network traffic mainly comprises of
      TCP traffic, especially HTTP traffic which contributes 77% of the
      traffic. Other significant TCP traffic includes HTTPS, SMTP, RTPS,
      and FTP traffic. While the UDP traffic and ICMP traffic
      contributes 14.61% and 0.49% of the traffic, respectively. Major
      network components were identified as follows.
      </i>
      <br>
  </li><li>
  
      <a href=papers/final-d.pdf>
      Network Situational Awareness
      Applying Concepts to a Specific Data Source
      </a><br/>
      Chris Canning, Joan Downing, Chris King,
      Bob Weiland
      <br><i>
      We were tasked with performing an analysis using the MAWI Sample
      Point Data F data set provided through the WIDE Project. Our
      analysis was based on data collected over 24 hours of network
      traffic on the 144.44.0.0/16 class B network, which will be
      referred to as .our network.. This network was chosen through
      analyzing the network traffic provided. Our network had the third
      highest flows and network traffic, so we figured this would
      provide us with enough data to perform a thorough analysis.
      <p>
      Our network was comprised of a number of Web Servers, DNS Servers,
      and Mail Servers, which were determined by analyzing flow traffic
      corresponding to services that would be hosted by the respective
      types of servers. Servers that processed a large amount of data on
      a known port would be more likely to host that service. In
      addition to servers, there were a number of client machines hosted
      on the network that had traffic similar to that of a normal user.
      </i>
      <br>
  </li><li>
  
      <a href=papers/final-e.pdf>
      A Network Flow Analysis of One Anonymous Class B Network 
      </a><br/>
      Michael Hanley, Brent Kennedy, Devon Rollins      
      <br><i>
      On March 31, 2009 starting at approximately 1500 hours GMT, the
      MAWI Working Group cooperated with CAIDA, The Cooperative
      Association for Internet Data Analysis, to conduct a large--.scale
      internet data collection project. The MAWI Working Group
      contributed by sampling a trans--.Pacific link using tcpdump1 to
      collect packet capture data and then annonimyzing and truncating
      the data using tcpdpriv2. This data appears to us to be in a
      network block--.preserving anonymized state, provides an
      incredibly valuable tool for students (undergraduate and graduate,
      alike) to perform traffic analysis both at the granular packet
      level, and with the appropriate tools, at a net flow level. For
      the purposes of this paper, 24 hours worth of packet capture
      (pcap) data from sample point .F. was converted to net flow data
      and packed into files compatible with the SiLK suite, developed at
      the CERT Coordination Center at Carnegie Mellon University.s
      Software Engineering Institute. We have been asked to analyze one
      /16 network from this dataset of our choice.
      </i>
      <br>
  </li><li>
  
      <a href=papers/final-f.pdf>
      Network Situational Awareness: Internet Traffic Analysis
      46.168.0.0/16
      </a><br/>
      Michael Scotto,
      Danial Ranjha
      <br><i>
      The following report discusses analysis of anonymized class B
      network 46.168.0.0/16. This network was chosen randomly from a
      list of all class B addresses in the MAWI data source on a major
      routing point in the internet. Data from the analysis was
      performed using the SILK network flow data analysis tool. During
      our analysis we acquired some very interesting
      information. Perhaps one of the most interesting finds is the lack
      of identifiable client traffic detected on the MAWI data
      collection point. We believe this to be caused by client traffic
      routing through a different other than our data source.
      </i>
      <br>
  </li>
  
</ul>

<h2>Fall 2008</h2>
<b>Assignment.</b>
In this project you will address a real-world scenario
by analyzing very large data sets which represent Internet-wide
collections.
<a href=project-fall2008.shtml>(more...)</a>
<p>

<ul>
  <li>
      <a href=papers/DecodingAnonymized-paper.pdf>
      Decoding Anonymized Packet Data
      </a><br/>
      Shawn McCaffrey, Shrikant Pandhare, Paul Pasquale and
      David Rennicker<br>
      <i>Through this report we intend to develop techniques for
      demystifying anonymous packet capture data. The first section of
      the report will talk about ways that a researcher can determine
      information about a population even with limited knowledge from
      packet capture data. The second section of the report will then
      talk about ways that a researcher can try and determine what
      services a user may be accessing based solely on the shape of the
      traffic flows. This will allow a researcher, if using data with
      anonymized IP addresses, to still be able to have an educated
      guess on what service is being accessed by a user. For the
      purposes of this report we will be focusing on media services,
      specifically play on demand audio and video, as well as live audio
      and video. The third section of the report will then show our
      attempts to use characteristics discovered in part two of the
      report, to try and find media services in flow data, and the
      challenges that this presents.</i>
      <br/>
  </li><li>
      <a href=papers/BruteForce-paper.pdf>
      Identifying Brute Force Host Access Attempts
      </a><br/>
      Joe McManus and Aaron Shelmire
      <br>
      <i>
      In our research we have studied the flow of traffic in an attempt
      to identify typical attack patterns, the successful attacks, and
      the resulting behavior of the hosts that have been
      attacked. ... Our study is focusing on the actions that occur when
      the service has already been found to exist. At this point the
      attacker will either try to exploit a known vulnerability in the
      protocol, or will attempt to gain access through poorly-protected
      account credentials.
      </i>
      <br/>
  </li><li>
      <a href=papers/TrafficManagementSystem-paper.pdf>
      Traffic Management Systems:
      An Impact Analyses
      </a><br/>
      Shuchi Muley and Mark Allen
      <br>
      <i>
      In the busy world of the Internet, users are pretty much able to
      derive any content they can imagine. With the limited amount of
      bandwidth available to ISPs, the growing concern they may have is
      regarding controlling the traffic to make improvements for
      efficiency. This project will serve as the analysis of the
      technical impacts of implementing a traffic management system.
      </i>
      <br/>
  </li><li>
      <a href=papers/MaliciousTrafficAnalysis-paper.pdf>
      Malicious Traffic Analysis
      </a><br/>
      Park Kittipatkul,
      Attila Csokai,
      Kevin Tropeck and
      Woon Chiat Sim
      <br>
      <i>
      On the surface, flow data entering and leaving a network looks the
      same. We can easily see the types of protocols used the IP
      addresses of hosts communicating and practically any statistics we
      may be interested in. However, the capture flow data in the right
      hands can reveal a lot more.
      <p>
      In this project, we will define various forms of malicious
      traffic, define its characteristics and isolate those traffic
      patterns entering and leaving an organization.s network using SiLK
      filters. If possible, we will also attempt to match these
      malicious traffic patterns to known malware behaviors.
      </i>
      <br/>
  </li>
</ul>
<p>&nbsp;
<p>&nbsp;
<p>&nbsp;
<p>&nbsp;

[an error occurred while processing this directive]