A SDN-based Flexible System for On-the-Fly Monitoring and Treatment of Security Events

The Software Defined Networking (SDN) paradigm decouples control and data planes, offering high programmability and a global view of the network. However, it is a challenge not only provide security in these next generation networks as well as allow that network attacks could be subjected to an incident and forensic treatment procedure. This paper proposes the implementation of flexible mechanisms of monitoring and treatment of security events categorized per type of attack and associated with whitelist and blacklist resources by means of the SDN controller programmability. The resources to perform intrusion and attack analysis are validated by means of a real SDN/OpenFlow testbed.

💡 Research Summary

The paper presents a practical implementation of a security‑oriented framework that leverages Software Defined Networking (SDN) to monitor, classify, and automatically react to network attacks in real time. Building on the observation that many existing SDN security proposals remain at the simulation or prototype stage, the authors develop a fully functional testbed that integrates the Ryu SDN controller with the Snort intrusion detection system (IDS). Two Python applications run on the Ryu controller: “switch_snort.py” configures an OpenFlow 1.3‑compatible WR1043ND switch as a Layer‑2 bridge and mirrors all traffic from a designated port to Snort, which operates in promiscuous mode; “mitigation.py” receives Packet_event messages generated by Snort whenever a rule is triggered, extracts the offending MAC address and attack signature, and invokes one of three pre‑defined flow‑handling routines.

The system classifies traffic into three categories. Class 1 represents normal traffic (e.g., FTP, SSH, HTTP). When Snort flags such traffic, the controller merely logs the event in a MySQL database for later analysis with the BASE tool. Class 2 covers probing activities such as port scans performed with nmap. Upon detection, the controller calls modify_table_flow, which rewrites all flow entries that match the attacker’s MAC address, redirecting the traffic to port 4 of the switch where a Honeyd honeypot is attached. This “trap” allows the defender to observe the attacker’s behavior while preventing further impact on production services. Class 3 includes denial‑of‑service attacks generated with hping3. In this case, drop_table_flow is invoked: the controller sends a DROP command to the switch to delete every flow associated with the malicious MAC address and simultaneously appends that MAC to a blacklist file. Subsequent flow‑creation requests from the blacklisted host are rejected, enforcing a default‑deny policy.

Whitelist and blacklist management is file‑based (whitelist.txt, blacklist.txt) and consulted each time a Packet‑in message requests a new flow entry. Only MAC addresses present in the whitelist are allowed to install flows; any address found in the blacklist is blocked outright.

The experimental setup consists of a low‑cost OpenWRT‑based WR1043ND OpenFlow switch, a Kali Linux attack machine, an Ubuntu server as the victim, a Honeyd honeypot, a Snort IDS with custom rules, a MySQL server for logging, and the Ryu controller running on a separate host. The authors conduct a series of controlled attacks: ICMP ping (Class 1), nmap scanning (Class 2), and hping3 flood (Class 3). For each scenario, Snort successfully generates a Packet_event, the controller processes the event, and the appropriate flow modification is applied. Measured reaction times range from 2 to 3 seconds, which the authors deem sufficient to halt ongoing attacks and prevent further compromise.

The results demonstrate that the proposed Intrusion Detection and Treatment System (IDTS) can seamlessly combine traditional IDS detection with SDN‑based flow control, providing a flexible, programmable, and centrally managed security mechanism. The authors acknowledge limitations such as the single‑point‑of‑failure nature of a centralized controller, potential scalability issues under high traffic loads, and the need for consistent policy enforcement across multiple switches. Future work is suggested to explore distributed controller architectures, load‑balancing among several OpenFlow switches, and integration with additional IDS platforms to broaden the defensive capabilities. Overall, the paper contributes a concrete, real‑world validation of SDN‑enabled dynamic security responses, moving beyond theoretical proposals toward deployable network protection solutions.