This section discusses the design and implementation of our flow-based proposal that intends to detect and mitigate DDoS attacks at their source domains. In addition, our solution protects some relevant Quality of Service (QoS) metrics for the flows that are associated with normal Web Services.
3.1. System Design
The proposed system uses a DDoS attack detection and mitigation mechanism that integrates an Intrusion Detection System (IDS) within the SDN architecture at the client side for either domestic or organizational networking scenarios.
The system operates via a loop control among three basic architectural components (Figure 1
): the network, the IDS, and the controller. The network represents all the data traffic and where a potentially DDoS attack might be launched. The IDS represents our DDoS attack detection mechanism, which analyzes all the traffic exchanged across the network. As the IDS detects an ongoing DDoS attack, the IDS notifies the Controller. After the Controller is notified by the IDS, the Controller transfers to the networking devices of the data path of some new flow rules for restoring the normal operation of the network as quickly as possible.
The system has three critical phases: detection, communication, and mitigation. The detection phase is about the system’s capability of detecting a DDoS attack. The communication phase occurs when the IDS alerts the controller about the detected DDoS attack. The mitigation phase is when the controller transfers some flow rules to the local switch, blocking the evil traffic. These flow rules are stored in a permanent way within that switch.
shows the conceptual model of the current work. Our proposal combines the functionality offered by both an SDN controller and an Intrusion Detection System (IDS). By aggregating these two entities, we have obtained an SDN-Based IDS Monitor. Each new Packet that arrives to the system (i.e., it was received in the switch’s port) is classified as belonging to a Flow and makes a Request to the system. In this way, the switch processes the received Packet according to a Rule associated to the Flow that Packet belongs to, making a Decision. In the case, the switch does not initially have any Rule for that Flow, then, the switch requests it to the SDN controller. The SDN controller installs the correct flow Rule in the switch which permits the Packet to proceed to its destination only if the packet belongs to a “well behaved” flow. Otherwise, a dropping Rule is installed in the switch. In this last case, the packets of the “bad” flow are discarded. The flow classification as “good” or “bad” is made by the IDS using a set of pre-configured rules. Each Request that is involved in a Flow results in a Decision from the developed system.
3.2. System Deployment
We have implemented the virtualized system that is visualized in Figure 3
as a proof-of-concept of the system’s model that was already presented in Figure 2
. Our system uses three different Virtual Machines (VM): VM A, B, and C. VM A contains two modules: the SDN Ryu controller and the Snort Intrusion Detection System (IDS). The SDN Ryu controller programs the network operation when specific flow-based events occur (e.g., after the controller has received an OpenFlow Packet_in
message). The SDN controller changes the network data plane via link (A)
, sending OpenFlow forwarding rules. The Snort IDS is our rule-based system is used to “fire an alarm” in the presence of an occurring DDoS attack. Hence, after the IDS detects a DDoS attack, it sends an alert packet via the Unix Domain Socket to the SDN controller, which is visualized in Figure 3
as link (D)
. Therefore, VM A has two network interfaces. The first interface (adapter 1) was configured as Host-Only (i.e., virtualized networking mode provided by the Hypervisor—VirtualBox) and it supports link (A)
communication. The second interface (adapter 2) was configured as the internal network (intnet
mode of the Hypervisor) and it supports link (B)
VM B emulates the network domain (e.g., home network) where a potential cyber-attack can be initiated. It runs a network emulator (i.e., Mininet) which deploys a network domain with some hosts, the software-based switch, and the NAT routing device. The software-based switch runs the OpenFlow protocol client part and belongs to the data plane of our testbed. This switch performs port mirroring and sends the entire traffic to the Snort IDS via link (B). The NAT device is used as a gateway for the hosts having access to the online server through link (C).
VM C represents an online server that can be potentially attacked by a DDoS threat. This VM has a single network adapter. This adapter was configured as Host-Only and it supports link (C) communication. In a nutshell, our testbed connections are as follows:
Bi-directional link (A) between the OpenFlow switch and the SDN controller which exchanges control traffic between the data and control planes—the Southbound Application Programming Interface (API);
Unidirectional link (B) between OpenFlow switch and Snort IDS which enables the switch to send all the mirrored traffic to the IDS for further analysis;
Bi-directional link (C) which connects the local network domain (i.e., VMs A, B) to the remote service;
Unidirectional link (D) which enables Snort IDS to notify the SDN controller (i.e., Ryu) about an ongoing DDoS attack through alert packets via the Unix Domain Socket.
represents the workflow of our system for each packet that arrives to the OpenFlow switch. The reader should now consider a usage scenario where a host tries to send a packet to the online resource. The OpenFlow switch receives that packet and tries to match it against the flow rules of its table. If no match occurs, then the switch requests to the controller a new rule for the new flow. Then, the controller responds by sending the new forwarding rule for that flow. Alternatively, if a match occurs within the switch, this means the switch already has a flow rule for that received packet. In this case, the switch forwards that packet according to the existing flow rule. In this way, the packet traverses the NAT gateway and proceeds towards the online service. In either case, the switch will mirror every received packet to Snort IDS. Then, the IDS analyzes the packet, processing it by means of a statistical function. This is designated as anomaly detection. In this specific case, the statistical function evaluates the mirrored packet as part of a malign flow. Then, the IDS notifies the SDN controller about this. By its turn, the SDN controller sends a blocking flow rule to the switch. The switch can mitigate the attack by eliminating all packets, matching the new installed blocking rule.
gives further details about how our solution operates in the presence of a DDoS attack driven by User Datagram Protocol (UDP) flooding and originated in a compromised internal host. We assume that the SDN controller has already installed a rule in the switch that normally forwards packets that originated from that host. We now explain the diverse processing steps a packet follows within our proposal. First, the ICMP Echo Request
arrives to the switch. Then, the switch forwards the ICMP Echo Request
to NAT. The switch mirrors with some latency (this depends on the internal switch fabric) the ICMP Echo Request
to the Snort IDS. While NAT forwards the ICMP Echo Request
to the Server and waits for the ICMP Echo Reply
, the Snort IDS in parallel analyzes the ICMP Echo Request
by means of a statistical function. If Snort considers that the processed packet has a statistically incorrect behavior, then the source node of that packet is classified as a malign host. Then, the IDS notifies the SDN controller about that via the Unix Domain Socket
. After this, the controller mitigates the attack by sending a rule to the switch that blocks future packets that originated from the discovered malign host. Hence, after receiving the previous dropping packet rule, the switch can protect the network resources against the malign packets as well as protecting the remote server from that attack. Nevertheless, the switch suffers from a slight processing overhead due to the mirroring
function. However, it is worth noting that this overhead is not so relevant in our domestic scenario.
To deploy our SDN-based IDS (see Figure 5
), we have aggregated the offered functionalities of an SDN controller and an IDS. The SDN controller is based on the open-source Python solution designated as Ryu [25
]. We have coded within this controller a Python function designated as process_snort_alert
. This function processes alerts received from the IDS. If the received alert is detected as a “Ryu block”, then that function sends a blocking flow rule to the Switch to otherwise ignore it. We have also used a well-known IDS, Snort [26
]. It detects attacks based on known rule signatures. We have configured Snort by editing the files snort.conf
as well as ddos_detection.rules
to consider our specific DDoS rules. These DDoS rules are used along the distinct testing scenarios of our proposal and allow the flexibility of our solution to adapt to other DDoS cyber-attacks.
The Mininet [27
] was used in our work to emulate the home network. This network was deployed using the Mininet Python API. For that, we created a Python script file. Inside that file, there are some instruction lines for deploying a NAT device within our topology. This NAT device works as a gateway between our emulated home network and the online remote service. The home network IP address is 10.0.0.0/8
. The online service IP address is 192.168.56.104
Our proposal uses Port Mirroring
for traffic monitoring. Port Mirroring
consists of duplicating packets that go in/out one switch’s port and forwards these packets to another switch’s port. To configure port mirroring
, we started by removing the IP address from the interface enp0s8
of the VM B (sudo ifconfig enp0s8 0
). Then, we used the ovs-vsctl
tool to add to the switch s1
a new port that connects to the interface enp0s8
(sudo ovs-vsctl add-port s1 enp0s8
). Next, we created a mirror, added it to the switch s1
, and finally configured it following the instructions from the OpenvSwitch Frequently Asked Questions (FAQ) web site (http://docs.openvswitch.org/en/latest/faq/configuration/?highlight=mirror
). The next section discusses the evaluation results of our current proposal.