Implementation of DiffServ Attacks and Data Collection in Linux

December 31, 2000


Project Title:

Protecting Network Quality of Service Against Denial of Service Attacks


N. C. State University

Contract Number:



Tolerant Networks

Project Website:




Our efforts during this period has focused on the following:


  1. Design and implementation of data flow attacks using Linux kernel module
  2. Analysis of the Linux DiffServ software and their implementation source
  3. code
  4. Implementation of DiffServ statistics monitor to periodically retrieve the PHB statistics from the Linux DiffServ software
  5. Analysis of the possibility to reuse the STAT module from our JiNao IDS system to efficiently detect data flow anomalies.



Design and implementation of data flow attacks


After we analyzed the possible attacks to DiffServ data flows, we came up with several requirements for our implementation of attacks. The attacks should not delay the packet or change the DiffServ behavior if not intended to. We should be able to dynamically reconfigure the attacks.


First, we investigated the divert socket for Linux which we implemented for several other projects. Because the divert socket implementation brings the packets from kernel space to user space and puts it back after the processing, it is slow and create huge delay. It doesn't satisfy our requirement. Next, we also looked at several other implementations such as netlink, netfilter, etc. They also cannot satisfy our requirements.


Next, we implemented the attacks within the Linux kernel using the kernel module. Also, we use the Linux proc file system(/proc) as the configuration file for the kernel module which provides the communication channel between user and kernel module. When the attack module is first loaded, it will register a file in /proc file system and user will update this attack configuration file to trigger the module to update its internal data structure.


When the attack module is implanted into the kernel, it will register a firewall and the firewall will be registered as the first firewall in the chain. All the packets will go through our code and then other processing.  We can manipulate the packets as we want to and send the packets back after our manipulation.


We are currently studying the performance of our attack implementation using the traffic generation tool MGEN-3.2.


Analysis of Linux DiffServ implementation


The Linux DiffServ implementation includes two fundamental parts. One is the kernel traffic control functions, such as Token Bucket Filter(TBF), Class Based Queueing(CBQ), Generalized Random Early Discard(GRED), FIFO, etc. The other is the user utility called traffic control (tc). The user applications use this utility to configure the kernel functions and also to get information from the kernel functions.


Each QoS device is first associated with a queueing discipline. Each queueing has a queue assigned to it. In the queueing discipline, filters are used to distinguish between classes.  Routers are configured using scripts to implement AF or EF classes.  For example, the AF class can be configured by using scripts that adjust CBQ or GRED parameters.


The tc utility uses netlink as the communication channel between user and kernel space. In order to display the current configuration and statistics of those kernel functions, it first opens the netlink device. Then it will dump the request to kernel functions and wait for the results from the kernel functions. They provide two libraries that implement the netlink and tc functionalities.



Design of DiffServ monitor


In our DiffServ monitor (dsmon) code, we use tc utility libraries to fetch the statistics from DiffServ kernel. The monitoring process will be a daemon and when it starts, it reads the configuration file which maps the DiffServ PHB classes to the queues, filters, and disciplines in DiffServ kernel functions. Then, periodically, it will report per PHB statistics to the detection engine.


After modification of the configuration file, we can use a SIGHUP signal to trigger the daemon to re-read the configurations. We are currently working on designing the configuration file and communication protocol between the daemon and the detection engine.



Analysis of JiNao STAT module


In the previous JiNao project, we designed, implemented and integrated the JiNao intrusion detection system. This system consists of three major detection components: rule-based prevention module, protocol-based detection module, and statistical analysis module. The statistical-based approach is based on the notion that network routing and management exhibit certain behavioral signatures. Any behavior deviating from the normal signature will be considered as an anomaly and appropriate alarms can be triggered. As one of the complementary components in JiNao system, the statistical analysis is intended to uncover those attacks that cannot be prevented by a set of rules embedded in a rule-based prevention module, or cannot be detected by security analysis conducted through protocol-based approach.


In this project, we notice that there are also certain behavior signatures in a DiffServ network. During this period, we investigated the possibility of reusing the statistical analysis module in JiNao system. The traffic throughput, dropping rate, packet delay in a DiffServ network also exhibit certain signatures. We are adopting JiNao statistical module to analysis the statistics collected by the monitoring daemons.



Plan and Directions


There's currently not any monitoring and intrusion detection specifically toward DiffServ networks. Although the DiffServ networks can provide a better service, there's few analysis about how the DiffServ network works. By providing the monitoring of DiffServ networks, we will provide the way to look at the performance of DiffServ network. The statistical analysis of the monitoring results will provide us a better view of the behavior of the DiffServ network.


We will use our audio application (tcptalk) to show the effects of different code points in the DiffServ network. There will be two user audio flows: one of them will be marked as EF traffic and the other, BE traffic. By using the monitoring process, we will collect the measures for each PHB provided by the kernel functions. By feeding these measures to the analysis engine, we will be able to detect several anomalies. Further investigation on how to analyze the measures will also be performed.