DIAMoND is a fully nonparametric, scalable,
distributed detection algorithm for intrusion/anomaly detection in networks.
DIAMoND frst builds coordination overlay networks on top of physical networks. DIAMoND then dynamically combines reports from traditional Firewalls and NIDSes with knowledge exchanged with other coordinating nodes such as switches or routers to dynamically detect anomalies of underlying physical systems. Specifically, coordinating nodes in DIAMoND exchange generic non-parametric levels of concern between nodes that reflect the observed probability of network attacks without elaborating any further details on the attacks themselves.
1.1 Communication Protocol
Each of the nodes participate in a periodic and spontaneous message exchange. As we try to keep the communication protocol complexity as low as possible, we define three basic messages:
Keep-alive messages are sent every several seconds depending on settings. They include: the message type, the time to live (TTL) value, and the level of concern. Messages are exchanged only between neighbors (see Figure 1 a-c). The reason we consider this type of messages is to make sure that we can always tell the difference between completely normal network state and the state where legitimate traffic is not delivered due to some packet losses (possibly caused by intrusive network activity). TTL reflects the number of logical hops between two communicating nodes. Ideally, TTL should reach 0 at the destination node.
Update messages have the same structure as keep-alive but are generated spontaneously when the level of concern increases or decreases due to either a change in a threat level or a change in a consensus of level of concern of the neighborhood. As previously, update messages are sent only to neighbors (see Figure 1 a-c). To reduce the potential of exploitation of the system, we limit the number of spontaneous messages possible to send between two successive keep-alive messages.
Summary messages are multicast to many participating nodes to report previously seen attacks and a node position so that the dynamic neighborhood can be potentially redefined according to a strategy, network topology changes, or recently observed attacks. The interval of summary messages could be set to every hour, day, or even week. We limit the lifetime (hop count) of this type of messages by TTL set to 255 (see Figure 1 d). The number of malicious source and destination IP addresses sent in one message is limited to 20.
For more detailed description of our algorithm or the communication protocol please contact us via e-mail:
feffermn at dimacs.rutgers.edu or maciej.korczynski at tudelft.nl. Please see below for links and example run commands for the environmental pieces.
2.1 Getting Started
We have developed our prototype communication controller as an OpenFlow component in the POX environment and evaluated in Mininet 2.0 simulator. It has been actively developed and supported. We encourage you to contribute code, bug reports, and anything else that can improve the proposed controller.
The easiest way to get started is to download a pre-packaged Mininet VM that includes Mininet itself, all OpenFlow binaries and pre-installed tools. In addition to standard Mininet installation, we provide our POX controllers, prototype implementation of the communication protocol, and some testing scenarios.
To install Mininet please download our Mininet VM image (based on Mininet version 2.0.0) and follow steps 2-5 of the Mininet VM Installation (recommended), as described here. After the installation we encourage to do the walkthrough and run the OpenFlow tutorial.
2.2 DIAMoND Components in POX
In this section, we discuss the DIAMoND components in POX, whereas the describtion of standard components that come with POX can be found here.
This component makes OpenFlow switches act as a "standard" type of L2 learning switch analogically to forwarding.l2_learning. However, it ignores the distributed-detection communication packets (Ethernet type 0x0105) that are exchanged between switches participating in the DIAMoND network.
This component can detect all kind of anomalies related to the TCP protocol locally, as described in the following paper: "An Accurate Sampling Scheme for Detecting SYN Flooding Attacks and Portscans".
This component is the most important part of the DIAMoND algorithm. In first place it creates neighborhoods (smaller subnetworks within which the information is exchanged) based on hop limits. Second, it combines levels of concern of its neighbors with a report from its internal NIDS (the local_detectors component).
This component has two options to determine the scope of the neighborhood and the level of trust of a switch to its neighbors: