Packet Sniffing To Determine Contents

Published Date: 02 Nov 2017

In today’s networked World, every network client demands "faster" speed of service delivery.

Network managers and administrators are heavily tasked to ensure that services are delivered on time and with minimal downtime, most Service Level Agreements (SLAs) specify uptime of 99.9% throughout every year. Many of these network technicians rely on tools that briefly inform them of the general conditions of their networks, others are too complex to use and yet in some cases network technicians rely on querying network devices interfaces like router interfaces to get relevant information regarding the status of their networks. Such are usually expensive in terms of time considering that interpreting the results of complex network tools or query results from router interfaces may take longer and may lack accuracy thus compromising meeting SLA conditions to the clients.

The type and size of workload in the network affects network performance in the following ways: fluctuation of the size affects key network performance metrics like response time and bandwidth while the type indicates whether the network is being used for the intended or malicious purpose.

In this project, we intend to use SNMP to gather relevant components of network traffic and use these to determine the kind and size of each key type of network workload. We will also use C programming language in addition to already existing sniffer tools to get the contents of packets in the network. Our main goal is to advise the Network technician of the impact of such workload type and size on the performance of the network. We thus aim to achieve the following:

Alert the network technician of the contents and size of what flows in through their network at any sampled time.

Reduction of network troubleshooting time.

Network manager can thus make appropriate decisions like prioritizing the most important workload.

Though not part of this project’s goal, gathered TCP/IP data and subsequent analysis may help in further proving that TCP/IP packet interarrival times are not Poisson, but rather follow a packet-train model.

Background to the Problem

I have spent many years as a network administrator. One of the most challenging tasks is acquiring and adapting network management tool which instantly and in a nut-shell displays the status of a network. Most available tools are either too costly or not addressing the exact problem.

Further, most of these tools do not reveal to the network administrators the fundamental problems that affect network performance metrics and when they are revealed, they are in a language not easily understood by humans such that by the time an administrator understands them, the entire network is already negatively affected. For example using tcpdump command like tcpdump -a in a linux environment. We need a tool that not only reveals the fundamental problems but also advises the network administrator of the general health of the network. Such a tool would involve the administrator in key decision making rather than summarily reporting the problem(s).

Network workload type and size are important data that every network administrator needs to know of. Due to the varying fluctuations of these two factors they intermittently affect the performance of a network. Our network management tool will zero in to these two types of workloads and proactively alert the administrator in case they are the root-cause of a problem.

Statement of the Problem

In this project, we will develop a software tool for network management, herein called Networkloadadvisor. It will capture performance data, key amongst these being workload size and contents from core network devices (routers, servers and switches) and report them to the administrator. In addition the network management tool shall use the other captured data to initiate some predefined advice to the administrator.

Objectives

This project aims to achieve the following:

Programmatically show the size of network workload on a given network device at any one given time.

To show the contents of network workload on a given network device at any one given time..

To advice the network manager of both the contents and size of traffic on the network and the consequences of each on key network performance metrics.

Research Questions

How do we use SNMP, RMON and C programming language to determine the size of workload in a network?

How do we sniffer onto network packets using RMON and C programming language to reveal the contents of captured network.

Having captured and analyzed the network data, at what point do we set the threshold and offer proactive advice to the network manager?

Justification

Most available network management tools are either too complex, fail to offer root-cause of network problems and where they do so such tools are too pricey for start-up companies in addition to being so complex to be used by inexperienced administrators.

We want to show the network administrator the raw factors that affect the performance of the network and at the same time offer advice.

In this way, we are able to leave room to the administrator to make parallel corrective decision based on available data and at the same time appreciating the uniqueness of different networks.

Expected Outcome

We expect to deliver the following:

Executable computer program that will meet the objectives in section 1.4.

Relevant program data file(s).

Program documentation.

User manual and sample program runs.

Scope of the Study

This study will be limited to LAN and PtP WAN.

Limitations

There are two outstanding limitations in this project:

Due its security nature, packet sniffing in most networks is a highly sensitive matter and will almost likely be denied by most organization managements if requested for. As such, one must build a proper case and show concrete benefits to the organization before being allowed to run a packet sniffer on an organization’s network. Secondly, request to run a packet sniffer in an organization is best dealt with at the I.T management level and not overall management since I.T management understands better the risks and the full benefits.

Secondly probing core network devices for their data workloads requires authentication and some especially on servers will require superuser logging. In most situations, no network/security administrators will share such like authentication details. We intend to approach this from use of SNMP public and private community strings in cases where the service is not set to run and in cases where the service is running, we will make official requests.

The other minor limitations in this project are time and sample network traffic for testing. We however will limit the scope so as to deal with as fewer variables as possible but still maintaining the core deliverables. On inadequate network traffic for use in setting up a threshold which is good enough to offer advisory role to the administrators. We hope that by targeting corporations with expected large network traffic, we will be able to handle this challenge reasonably well.

Basic Assumptions

We make basic assumptions that SNMP in the network devices is not set and therefore are still using default community strings public and private. Our software will however start by probing the devices and advice with a list of what has been changed and what has not been changed. Where changes have been made, we shall make official requests.

We also assume that the network we are sniffing is not encrypted.

Definition of Terms

Client: Herein defined as the human user or system that is responsible for generating workload(s).

Frame: A logical unit of information sent by the Data Link Layer over a transmission medium.

MAC: Media Access Control, the lower sub layer in the Data Link Layer which is responsible for hardware addressing, media access and error detection of frames

Packet: The basic logical unit of information transferred. It consists of data bytes encapsulated in headers and/or trailers that contain information such information like addresses from and to.

Protocol: The specification of a set of rules for a particular type of communication. Term also refers to the software that implements the set of rules.

Protocol Analyzer: A tool that is used to analyze packets on any transmission line.

Workload: Requests to a system made by clients.

Proposal Outline

This proposal is organized into three chapters as summarized below:

Chapter one: Introduction

This chapter introduces the proposal with the listing of the objectives and the rationale why we think it is important to carry out this work.

Chapter two: Literature review

Chapter two looks at what has been done by others in relation to the same topic.

Chapter three: Methodology

This chapter looks at different research approaches hence leading to formulation of the chosen framework.

CHAPTER TWO: LITERATURE REVIEW

This chapter looks at theories, other tools and some standards which are already in place elsewhere.

We take a brief moment to look at Fault Management, Configuration Management, Accounting Management, Performance Management and Security Management (FCAPS), an ISO framework to aid in understanding major functions of network management systems Subramanian, M. (2011). Our focus will be on Performance management which is more related to what we are covering.

Network Management

Security Management

Performance Management

Accounting Management

Configuration Management

Fault Management

Goal is to control access to network/host resources and also to detect and prevent attacks on network/hosts.

Security includes network and physical components. Network security includes:

Firewalls.

IDS.

IPS.

Antivirus.

Policy management and enforcement.

Aim is to measure and report on various aspects of network and system performance.

Steps:

Gather performance data.

Establish baseline levels based on analysis of gathered data.

Establish performance thresholds.

Report as faulty incase thresholds are exceeded.

Aim is to ensure computing and network resources are fairly used amongst groups or individuals.

Goal is to monitor configuration on system and network so that effects on network operation may be tracked and managed.

Some configuration parameters to capture:

O/S version & firmware.

No. of network interfaces and their speeds.

No. of CPUs and amount of RAM.

…

Detects, logs and notifies users of network problems.

Fault Resolution Steps:

Isolate problem.

Resolve problem.

Record resolution and detection process.

Figure 2.1: A diagram depicting ISO’s conceptual areas of major network management.

Packet Headers

We take a look at the following packet headers as well an overview look at TCP/IP family of protocols which will help us to understand what we shall be processing.

User

Process

User

Process

OSI Layers 5-7

UDP

TCP

OSI Layer 4

RARP

ARP

IP

ICMP OSI Layer 3

Hardware

Interface

Figure 2.2: Layering in the IP suite. Stevens, W. Richard. (2002).

Ethernet Frame

According to Barry Nance (2002) and Todd (2005) an Ethernet frame looks as follows:

Preamble

Destination

Source

Type

Data

FCS

8 6 6 2 46-1500 4

Length of each field in bytes

Figure 2.3: Ethernet_II frame showing the length of each field in bytes.

Preamble: An alternating 1,0 pattern provides 5MHz clock at the start of each packet which allows the receiving devices to lock the incoming bit stream.

The Start Frame Delimiter (SFD)/Synch consists of a single byte with the bit pattern 10101011 where the last pair of 1s allows receiver to come into the alternating 1,0 pattern somewhere in the middle and still sync up and detect the beginning of data.

Destination address: Field transmits a 48bit value using the least significant bit first. It is used by receiving stations to determine whether an incoming packet is addressed to a single node, broadcast or multicast MAC address.

Source address: a 48-bit MAC Source address of the transmitting device. It also uses LSB first. Broadcast and Multicast address formats are illegal within this field.

Type: Identifies Network layer protocol.

Data: This is the actual packet. Size varies from 46 to 1500 bytes.

FCS: Frame Check Sequence is a field at the end of the frame used to store CRC.

IP Header

Figure 2.4: IP Header showing the beginning and end of each length in bytes.Sourced from security-freak.net

TCP Header

Figure 2.5: TCP Header. Indicated lengths are in bytes. Sourced from security-freak.net

UDP Header

Figure 2.6: UDP Header. Indicated lengths are in bytes. Sourced from security-freak.net

SNMP

SNMP is an acronym for Simple Network Management Protocol and is a standard defined by IETF for managing IP devices. Examples of such devices can be routers, switches, servers, workstations, printers, UPS. It can also manage operating systems and database systems.

SNMP evolved from Simple Gateway Management Protocol (SGMP) which was developed to manage internet routers.

SNMP is based on a manager/agent model which consists of a manager, agent, database of management information, managed objects and network protocol. It uses UDP as a transport protocol between managers and agents on ports 161(send and receive requests) and port 162 for receiving traps.

The manager and agent use a Management Information Base (MIB) and a relatively small set of commands to exchange information. The MIB is organized in a tree structure with individual variables, such as point status or description, being represented as leaves on the branches. A long numeric tag or object identifier (OID) is used to distinguish each variable uniquely in the MIB and in SNMP messages.

SNMP uses five messages (GET, GET-NEXT, GET-RESPONSE, SET, and TRAP) to communicate between the manager and the agent.

There are three versions of SNMP:SNMPv1 which is the initial version of SNMP and is defined in RFC 1157. It has weak security since community strings (equivalent to passwords) are in plain text strings that allows any SNMP-based application with the string to gain access to the device’s management. SNMPv2 which is based on RFC 3416-18 and is also not very secure. The relatively secure version is the latest version, SNMPv3 based on RFC 3410-18 and RFC 2576.

RMON

RMON is an acronym for Remote Monitoring and is a community defined standard with the help of IETF, RFC 1757.

The specification defines a set of statistics and functions that can be exchanged between RMON console managers and network probes

According to cisco.com, it provides network administrators with comprehensive network-fault diagnosis, planning, and performance-tuning information.

RMON delivers information in nine RMON groups of monitoring elements, each providing specific sets of data to meet common network-monitoring requirements. Each group is optional so that vendors do not need to support all the groups within the Management Information Base (MIB).

RMON GROUPS

GROUP

FUNCTION

ELEMENTS

Statistics

Contains statistics measured by the probe for each monitored interface on this device.

Packets dropped, sent, bytes sent (octets), broadcast packets, multicast packets, CRC errors, runts, giants, fragments, jabbers, collisions, and counters for different packet ranges

History

Records periodic statistical samples from a network and stores them for later retrieval.

Sample period, number of samples, items sampled.

Alarm

Periodically takes statistical samples from variables in the probe and compares them with previously configured thresholds. If the monitored variable crosses a threshold, an event is generated.

Includes the alarm table and requires the implementation of the event group. Alarm type, interval, starting threshold, stop threshold.

Host

Contains statistics associated with each host discovered on the network.

Host address, packets, and bytes received and transmitted, as well as broadcast, multicast, and error packets.

HostTopN

Prepares tables that describe the hosts that top a list ordered by one of their base statistics over an interval specified by the management station. Thus, these statistics are rate-based.

Statistics, host(s), sample start and stop periods, rate base, and duration.

Matrix

Stores statistics for conversations between sets of two addresses. As the device detects a new conversation, it creates a new entry in its table.

Source and destination address pairs and packets, bytes, and errors for each pair.

!RMON Group

!Function

!Elements

Filters

Enables packets to be matched by a filter equation. These matched packets form a data stream that might be captured or that might generate events.

Bit-filter type (mask or not mask), filter expression (bit level), conditional expression (and, or not) to other filters.

Packet Capture

Enables packets to be captured after they flow through a channel.

Size of buffer for captured packets, full status (alarm), and number of captured packets.

Events

Controls the generation and notification of events from this device.

Event type, description, last time event sent.

Table 2.3: RMON Groups.

Packet Sniffing to determine contents

The main goal in packet sniffing is to get all the headers on a network (Ethernet, TCP, IP amongst others) and analyze them for their contents.

This can be achieved in a promiscuous mode or non-promiscuous mode.

The promiscuous mode turns the network driver to accept all packets irrespective of whether they were addressed to it or not.

TCPDUMP

This is a wonderful tool for network packet capture from the network interface.

According to the manual pages available at the tcpdump’s official webpage, tcpdump prints or can savet a description of the contents of packets on a network interface that matches a given boolean expression.

It has several options which can be used to determine what and how packets are captured.

In its original form, it is command line based and requires a mastery of its options and commands of the platform in which it running on.

An typical command in linux/unix environment that filters host IP addresses based on the most frequent user of the ARP protocol would go as follows:

#tcpdump -l -n arp | grep 'arp who-has' .

CHAPTER THREE: METHODOLOGY

Proposed Framework

The proposed framework will make use of SNMP, RMON and C programming language to achieve the three main objectives in section 1.4 and as well answer the research questions in section 1.5.

The system will have four main modules:

Module one will address the user interface which will link the user with the entire system.

Module two will be responsible for capturing workload size and will have an interface with SNMP and RMON.

Module three will be responsible for capturing workload contents and will have an interface with RMON and the C code for wire sniffing.

Module three will be concerned with reporting and advising. This will be done via graphical and text based methods.

Having developed the system, we will capture data from the corporate LAN and use the same for testing.

Workload content methods

Our workload content method will involve Raw-Socket sniffing and will involve by-passing the network interface of the host and communicate directly with the drivers.

Additionally, where possible and easily achievable, we shall use RMON and tcpdump interface from our system to capture the data.

Workload Size methods

The workload size method will make use of SNMP by creating an appropriate interface to interact with it, capture the relevant data, process it and store it in an appropriate database.

Time Plan

DATE OR MONTH

DELIVERABLE

DURATION

Dec 2011

Title selection

1 Week.

March 2012

Project proposal

2 Weeks.

March 2012

19/3/2012 to 31/3/2012.

Literature Review of related works

3 Weeks.

April 2012

1/4/2012 to 21/4/2012

Requirements specification.

Functional Specifications.

3 Weeks.

April 2012

21/4/2012 to 9/5/2012

Functional Specifications.

System Design.

4 Weeks.

May 2012

10/5/2012 to 24/5/2012

Testing and Debugging.

2 Weeks.

May 2012

Progess report presentation

2 Weeks.

June 2012

Evaluation, Analysis and conclusion with Complete project report as the deliverable.

4 Weeks

July 2012

Oral presentation of Evaluation, analysis and conclusion

2 Weeks.

Table 3.4: Project Time Plan.