Source-linked AI summary
SDN-Based Intrusion Detection System for Early Detection and Mitigation of DDoS Attacks
Pedro Manso, Jose Moura, Carlos Serrao
TL;DR
IoT device weaknesses have enabled DDoS attacks that can disrupt online services, while distributed sources make neutralization difficult. This paper combines an IDS with an SDN controller to detect attacks and install source-side blocking rules. In its UDP test scenarios, the system detected attacks with a 3.07 s average mitigation time while reporting 0.541 milliseconds average RTT and no noticeable packet loss.
Problem
Compromised IoT devices can generate distributed DDoS traffic that exhausts server resources and keeps services down while attack sources are difficult to neutralize.
Source: §1 · pp. 1–2Method
The system analyzes mirrored traffic with an IDS and alerts an SDN controller, which installs flow rules to block malicious traffic at its source.
Source: §1 · p. 2, §3.2 · p. 5Results
Across UDP DDoS, IP-spoofing, and IP-packet-size-manipulation scenarios, average mitigation time was 3.07 s, average RTT was 0.541 milliseconds, and no noticeable packet loss occurred.
Source: §5 · p. 15Takeaways & Limitations
The authors conclude that a client-side SDN security system can help mitigate DDoS attacks while maintaining normal network operation.
Source: §5 · p. 15The system should be able to forget formerly malicious devices so they are not permanently blocked after an attack they enabled to some degree.
Source: §5 · p. 16
Abstract
from arXiv · showhide
The current paper addresses relevant network security vulnerabilities introduced by network devices within the emerging paradigm of Internet of Things (IoT) as well as the urgent need to mitigate the negative effects of some types of Distributed Denial of Service (DDoS) attacks that try to explore those security weaknesses. We design and implement a Software-Defined Intrusion Detection System (IDS) that reactively impairs the attacks at its origin, ensuring the normal operation of the network infrastructure. Our proposal includes an IDS that automatically detects several DDoS attacks, and then as an attack is detected, it notifies a Software Defined Networking (SDN) controller. The current proposal also downloads some convenient traffic forwarding decisions from the SDN controller to network devices. The evaluation results suggest that our proposal timely detects several types of cyber-attacks based on DDoS, mitigates their negative impacts on the network performance, and ensures the correct data delivery of normal traffic. Our work sheds light on the programming relevance over an abstracted view of the network infrastructure to timely detect a Botnet exploitation, mitigate malicious traffic at its source, and protect benign traffic.
1. Introduction
The growth of Internet-connected devices increases opportunities for attackers, while IoT weaknesses have enabled large DDoS attacks that are difficult to neutralize. The paper proposes an SDN-based IDS that detects attacks and enables mitigation at their origin while aiming to preserve benign users’ QoS.
1. Introduction
- Internet use and connected-device numbers were growing, creating more infrastructure that attackers could exploit.The passage reports that more than half of the world population used the Internet in early 2018 and cites a forecast of 27.1 billion devices worldwide in 2021.Source: §1 · p. 1
- The 2016 Mirai attack used compromised IoT devices across geographically separated domains to flood servers, whose services remained down for hours because neutralizing every source was difficult.The devices generated high traffic simultaneously toward specific Internet servers.Source: §1 · pp. 1–2
- The authors propose comparing expected and monitored traffic trends, alerting an SDN controller on significant deviations, and using controller flow rules to block malicious traffic at potential sources.The proposal aims to preserve benign users’ QoS and accommodate other DDoS attack types.Source: §1 · p. 2
2. Related Work
Prior DDoS defenses include signature- and anomaly-based detection, but the cited approaches have limits in attack coverage or training demands. The authors propose event-triggered anomaly detection and source-domain blocking as an alternative to clustering-based mitigation.
2. Related Work
- Signature-based defenses can miss novel attacks or variants; cited examples also either address SYN floods only or fail to distinguish benign from malicious traffic.Other cited work integrates an IDS with SDN.Source: §2 · p. 2
- Anomaly-based approaches classify deviations from learned normal behavior, but the cited proposals require considerable supervised training before efficiently detecting attacks.Source: §2 · p. 2
- The authors identify source-domain mitigation as uncommon in prior work, noting clustering-based exceptions and proposing threshold-triggered detection with blacklist-based OpenFlow blocking at attack sources.They describe clustering as potentially costly to manage and capable of creating bottlenecks or inaccurate decisions.Source: §2 · pp. 2–3
3. Design and Deployment of Our Flow-Based Proposal Thwarting DDoS Attacks
The proposal combines an IDS and SDN controller to detect DDoS traffic and install blocking flow rules at source domains. Its design and virtualized deployment mirror traffic to Snort for analysis while the switch and controller continue forwarding or block traffic according to flow rules.
3. Design and Deployment of Our Flow-Based Proposal Thwarting DDoS Attacks
- The proposal is a flow-based system intended to detect and mitigate DDoS attacks at source domains while protecting QoS for normal web-service flows.Source: §3 · p. 3
3.1. System Design
- The system’s network, IDS, and controller form a loop: the IDS alerts on an attack, and the controller sends new flow rules to restore normal network operation.The phases are detection, communication, and mitigation; mitigation rules block malicious traffic at the local switch.Source: §3.1 · p. 3
- Packets are classified into flows and handled by switch rules; when no rule exists, the controller installs a forwarding rule for a good flow or a dropping rule for a bad one.The IDS classifies flows using preconfigured rules.Source: §3.1 · pp. 3–4
3.2. System Deployment
- The virtualized deployment places Ryu and Snort on VM A, a Mininet-emulated network and switch on VM B, and the potentially attacked online server on VM C.The switch mirrors traffic to Snort; the IDS sends alerts to Ryu, which can send flow rules to the switch.Source: §3.2 · pp. 4–5
- For each received packet, the switch matches or requests a flow rule while mirroring traffic to Snort, whose analysis can trigger a controller rule that blocks matching packets.In the described UDP-flood sequence, Snort analyzes a mirrored ICMP Echo Request while NAT forwards it; a detected malicious source is blocked from sending future packets.Source: §3.2 · pp. 5–6
- Snort uses configured DDoS rules, while the Ryu controller processes IDS alerts through a function that sends a blocking rule when an alert is detected as a Ryu block.The configured rules are intended to support different testing scenarios and adaptation to other DDoS attacks.Source: §3.2 · pp. 6–7
- The testbed uses Mininet to emulate a home network with a NAT gateway connecting hosts to the online service, and port mirroring duplicates switch traffic for IDS monitoring.Source: §3.2 · p. 7
4. Results
The evaluation tests three DDoS scenarios and reports detection and mitigation alongside effects on benign traffic. Across the scenarios, attack traffic is blocked and normal traffic is reported to remain stable or return to its usual load.
4. Results
- The tests use hping3 to send customized TCP/IP packets and assess mitigation time, average RTT, and packet loss.The study also describes a simulated home network and its attack scenarios.Source: §4 · p. 7, §4.1 · pp. 7–8
4.1. Tests’ Description
- The evaluation uses three scenarios to test functional aspects of the proposal, not a testbed with thousands of nodes.The scenarios include spoofed-IP and packet-size manipulation attacks, each with one malicious host and two benign hosts.Source: §4.1 · pp. 7–8, Table 2 · p. 7
4.2. Results Presentation and Discussion
- With the defense disabled, DDoS traffic peaked slightly above 42,000 packets/s after 50 seconds; the no-attack tests also report typical QoS metrics.The tests compare attack conditions with typical network behavior, including the flow-rate variation of a benign host during the first scenario.Source: §4.2 · p. 9, §4.2.1 · p. 9, Table 3 · p. 9
4.2.1. Scenario I
- About five seconds on average were needed to detect and mitigate the two-host DDoS attack, after which network traffic stabilized near its normal status.The reported performance measures include mitigation time, average RTT, and packet loss.Source: §4.2.1 · p. 11, Table 4 · p. 11, Figure 12 · p. 11
4.2.2. Scenario II
- In the spoofed-IP scenario, host rates remained constant, and the attack was blocked two seconds after launch as traffic returned to its usual load.The switch installed a higher-priority drop rule for packets matching the malicious host and server addresses.Source: §4.2.2 · pp. 11–12, Table 5 · p. 13, Figure 15 · p. 13
4.2.3. Scenario III
- In the large-packet scenario, hosts 2 and 3 kept unchanged transmission rates, and the attack was mitigated in nearly three seconds.The detection rule targeted packets larger than 800 bytes from the 10.0.0.0/8 network to the server; Table 6 reports mitigation time, average RTT, and packet loss.Source: §4.2.3 · pp. 13–15, Table 6 · p. 15, Figure 18 · p. 15
5. Conclusions
The client-side SDN security system detects DDoS scenarios and limits them at their origin. In tested UDP scenarios, it detected all attacks with an average mitigation time of 3.07 s, while the authors identify reducing IDS control events as important to avoid controller congestion.
5. Conclusions
- 3.07 s average DDoS mitigation time, 0.541 milliseconds average RTT, and no noticeable packet loss were reported across three UDP attack scenarios.The scenarios were DDoS, DDoS with IP spoofing, and DDoS with IP packet size manipulation.Source: §5 · p. 15, Table 7 · p. 16
- The authors identify reducing IDS-to-controller control events as important because congestion can delay attack discovery and mitigation.They report that an overloaded SDN controller takes too much time to discover and mitigate a DDoS attack.Source: §5 · p. 15
- The proposal has room for improvement, including a capability to “forget” ex-malicious devices rather than leave them permanently blocked after an attack they enabled.The authors also suggest machine-learning techniques could complement their rule-based detection mechanism to help detect new and sophisticated attacks.Source: §5 · p. 16
- The authors favor defense close to rogue-traffic sources and describe provider collaboration, including flow analysis through federated SDN controllers, as part of that approach.The proposed collaboration includes validating packet source addresses and deploying flow-based filtering features.Source: §5 · p. 16