SDNHive: A Proof-of-Concept SDN and Honeypot System for Defending Against Internal Threats

Nowadays, ransomware attacks are becoming more popular because they allow attackers to receive ransom payments from their victims. While older ransomware used to spread using social engineering means, modern ransomware tends to also be equipped with worm-like features. This allows it to propagate from the initially infected device to other computers in the same network. Those attacks motivated us to propose SDNHive, a proof-of-concept SDN and Honeypot-based protection system that can protect clean devices from being attacked by ransomware-infected devices in the same network. For intrusion protection, SDNHive implements address blacklisting, connection blocking, and transparent traffic rerouting inside the controller. These functions are called by the honeypot through our custom API once malicious activities are detected. Therefore, the honeypot in our system is not simply a decoy host, but a real intrusion detection device that can detect SMB and ARP scans. Our system is unique since state-of-the-art systems use only the SDN controller for both detection and protection. Still, we also implement the SMB and ARP scan detection functions inside the SDN controller as well in order to compare both SDN-only and SDN+Honeypot approaches. To demonstrate the performance of SDNHive, we create a Virtual Malware Testbed that simulates a real-life network with the ONOS SDN controller, the honeypot, and a mix of Linux and Windows virtual machines. We evaluate our system by using it to prevent WannaCry, a well-known SMB ransomware, from propagating to other hosts inside our testbed. Additionally, we also monitor CPU usage for each of the functions inside the system. When using only the SDN controller, our system is able to detect WannaCry within 20 seconds from the start of the propagation. The CPU usage stays at about 20 percent. However, when we make both the SDN controller and the honeypot work together, WannaCry is detected in only 2.5 seconds, and the CPU load is negligible. This proves that our SDN+Honeypot approach is better than the current SDN-only solutions.