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
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
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.
l2_learning-modif
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.
local_detectors
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".
anomaly_detector
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:
- --ttl defines the neighborhood based on a hop limit that reflects the geographical or administrative distance. In other words, nodes exchange their levels of concerns with their direct neighbors (ttl=1) or their neighbors and neighbors of their neighbors (ttl=2), and so on.
- --algo defines the level of trust to all switches belonging to node's neighborhood. Possible values are: "low", "med", "med+", and "high".
Example run command syntax:
- sudo ./pox.py anomaly_detector --ttl=2 --algo="med" l2_learning-modif openflow.discovery log.level --WARNING --anomaly_detector=DEBUG --local_detectors=DEBUG
And example run command syntax to build the Mininet network:
-
sudo mn --switch ovsk --controller=remote,ip=127.0.0.1,port=6633 --custom ~/mininet/custom/topoStar7pro.py --topo star7pro
anomaly_detector2
This component has one more option in comparison to anomaly_detector.
- --strategy defines the strategy of neighborhood creation. In addition neighborhood based on the hop limit (option: "neig"), we propose to correlate previously observed attacks and construct neighborhoods based on the assumption that malicious activity may reoccur and be launched from the same set of compromised machines and/or against the same victims (option: "anom")
Example run command syntax:
-
sudo ./pox.py anomaly_detector2 --ttl=1 --algo="med+" --strategy="anom" l2_learning-modif openflow.discovery log.level --WARNING --anomaly_detector2=DEBUG --local_detectors=DEBUG
You may also run the following command with physical Mininet topologies that contain loops:
-
sudo ./pox.py anomaly_detector --ttl=1 --algo="med" l2_learning-modif openflow.discovery openflow.spanning_tree --no-flood --hold-down log.level --WARNING --anomaly_detector=DEBUG --local_detectors=DEBUG --openflow.spanning_tree=DEBUG
You might try to check the effectiveness of the algorithm when some switches behave as a type of "typical" L2 switch and some other can be in addition equipped with the DIAMoND algorithm:
-
sudo ./pox.py openflow.of_01 --port=6633 anomaly_detector --ttl=1 --algo="med" l2_learning-modif log.level --WARNING --anomaly_detector=DEBUG --local_detectors=DEBUG
-
sudo ./pox.py openflow.of_01 --port=6644 forwarding.l2_learning log.level --WARNING
Finally, the structure of our network layer protocol is discussed and can be found in /home/mininet/pox/pox/lib/packet/bee.py, whereas further examples can be found in /home/mininet/maciej/tests/
In order to explore the impact of network configuration on the success of the distributed detection of DIAMoND, we tested the performance of the algorithm on a variety of network topologies (each with a total network size of 20 nodes due to computational constraints). These included "Full Mesh", "Mesh", "Bipartite", "Linear", and "Extended Star", defined as follows:
"Full Mesh" is the complete undirected network on 20 nodes, involving n*(n-1)!/n=190 edges.
"Mesh" is a randomly selected subgraph of Full Mesh in which the probability of each edge is 0.3, therefore involving 0.3*n*(n-1)!/n=57 edges for each realization.
"Bipartite" is the division of the network into two sets of size 10, with the probability of 0.6 for an edge between nodes from different sets and a probability of 0 for an edge between nodes in the same set, therefore also involving 0.6*n*(n-1)!/2n=57 edges for each realization.
"Linear" is a single path of edges among the nodes, i.e. a connected graph in which 2 nodes have exactly 1 incident edge and all others have exactly 2 incident edges, therefore involving (n-1)=19 edges.
"Extended Star" is a tree, created by initiating the graph with 1 node and then attaching each subsequently created node to one of the already existing nodes with uniform probability until the network size reaches 20, therefore involving (n-1)=19 edges.