You are here:   Software
  |  Login

Potential Covert Channel Manipulation Detector (based on the IPv4ID)


A Potential Covert Channel Manipulation Detector based on the IPv4 header ID field analysis has been developed in C# on Microsoft .NET Framework using Visual Studio .NET, which includes the following features:
  • Automatic traffic request engine, from which networks packets are required to be sent from a specified host by requesting the default web page once and again within a loop.

  • Incoming traffic monitor, which permits to specify what fields from the IPv4 header are required to be shown.

  • A connection performance meter, to know how many packets per minute are received from that connection.

  • A detection algorithm control panel. Potential covert channels detection is based on the position within a range of values in an internal counter called Covert Channel Meter, specified by a Minimum and Maximum value.

    Minimum value means low risk of potential covert channel manipulation, and Maximum value means high risk.

    Each time a network packet is received the value of the IPv4ID field is compared with the previous one. If the difference is within the Jump Range value, what is specified in the Increment Count field is added to the Covert Channel Meter.

    Otherwise, what is specified in the Decrement Count is subtracted from the Covert Channel Meter. Due to sometimes it has been observed breaks within the sequence where the value in the IPv4ID field is set to a lower value (or 0), an option to take into account or ignore Negative Jumps have been implemented.

    By adjusting these parameters, potential covert channels based on the manipulation of the IPv4ID field can be detected. This algorithm is based on the current implementations of the TCP/IP drivers in the major important operating system in the market.

  • Data logger, that records the information received from the two connections that can be managed simultaneously from the application.
Monitor, Filters and Counters

In order to conduct this work, a research about how the IPv4 header ID field is implemented in the major operating systems in the market has been carried out. These are the results:
  • The IPv4ID generation algorithm is initialized in Linux associated with the TCP socket, and it's an incrementing sequence from there.

  • In SUN Solaris, the IPv4ID is initialized with a secure random number. IDs are simply incrementing from there or randomized each time is needed. It uses distinct counters for each destination IP address.

  • The IPv4ID algorithm in OpenBSD uses a linear congruential generator, rekeyed every 3 minutes (or after 30,000 IDs have been generated, whichever is sooner).

  • In MS Windows, the IPv4ID increases monotonically until reaching the maximum value of 65533, and then starts again from 0.
What it can be seen from this is that the major implementations in the market follow the legal framework of the protocol, which is that the sender must choose the identifier to be unique for this source for the time the datagram (or any fragment of it) could be alive in the internet, but in a different way that is suggested by RFC 791, which is that the sending protocol module should keep a table of unique Identifiers to manage the exclusivity of that identifier.

Instead of that, current implementations sequence the number.

Oscilloscope and Detector

Click here to see a full screenshot.


University of St Andrews     University of St Andrews
School of Computer Science
North Haugh
St Andrews KY16 9SX
Scotland
UK

Distributed-System Monitor for Potential Covert Channels Analysis


It consists of software components that work separately and concurrently. A distributed-system monitor is divided into a number of layers. Each layer makes use of the services provided by the lower layers and extends the available facilities to the upper layer. The layers are briefly introduced:

Observation: This layer gathers raw data on individual components of the system. Generally, each component may have an observer designed specifically for it. Thus there may be several observers located on different subsystems.

Collection: This layer collects data from various observers. It is possible to have more than one collector on large systems. Collectors may coordinate the activities of observers across the network and sometimes be responsible for store and forward activities for collectors situated on other nodes.

Analysis: This layer analyzes the data gathered at various collectors. It may consist of various statistical routines to summarize the data characteristics. Simple analysis such as counting of events is done most efficiently in the observer but more complex statistical calculations are performed here.

Presentation: This component of the monitor deals with human user interface. It produces reports, displays, and alarms. The presentation layer may be integrated within another tool that may manage some part of the system.

Interpretation: This component refers to an intelligent entity (human or expert system) that can make meaningful interpretations of the data. This generally requires multiple rules and trend analyses. Simple threshold-based alarms may be considered part of the presenter rather than of the interpreter which usually requires the application of more sophisticated rules.

Console/Control: This component provides an interface to control the system parameters and states. Strictly speaking console/control is not a part of the monitor. However, the monitoring and control functions are often used together and it is desirable to allow system control as well as system observations facilities to be used together.

Management: The entity that makes the decision to set or change system parameters or configurations based on interpretation of monitored performance is called the manager. A software manager component exists only in monitors with automated monitoring and control facilities.

Distributed Monitor

The distributed-system monitor consists of multiple components from each of the layers listed above. There is a many-to-many relationship between successive layers. A single collector may gather data from multiple observers. Many analysis layers may use data gathered by a single collector. Several collectors may be acting with a single observer, etc. Interpretation, Console/Control and Management layers can also be automated but they are often done by humans. For this reason the distributed-system monitor here is designed taking into account layers from the Observation to the Presentation, which includes a console for managing the whole system. The components of the distributed-system monitor are able to operate at any location on the Internet:

Observers analyse traffic from specific segments of the network.

Collectors are distributed taking into account, for instance, traffic payload capabilities.

Analysers work in a specific mode according to a particular strategy within a scenario.

Presenters show the system management and results in the appropriate view based on the context.