Detecting Suspicious Behavior of SDN Switches by Statistics Gathering with Time

Transcription

1 Detecting Suspicious Behavior of SDN Switches by Statistics Gathering with Time Takahiro Shimizu, Naoya Kitagawa, Kohta Ohshima, Nariyoshi Yamai Tokyo University of Agriculture and Technology Tokyo University of Marine Science and Technology APAN Research Workshop 2018 August 6 th, 2018

2 2 Outline Background Related Work Proposed Method: Forwarding state verification with scheduled statistics gathering Experiment Discussion Conclusion

3 3 What is Software Defined Network (SDN)? Decouples network control and packet forwarding function Enables flexible network control by centralized control plane Controller is programmable Maintains a global view of the entire network, thus enable efficient routing OpenFlow: A protocol to realize SDN CP DP CP DP Switch CP DP Traditional Network CP DP Controller CP DP DP DP DP SDN Switch Software Defined Network

4 4 Background Software Defined Network: often used programmable software switches Increase probability of compromise than traditional hardware switches CVE : buffer overflow vulnerability caused by compromised MPLS packet in Open vswitch

5 5 Background Attacks possible from compromised switches Packet misrouting Packet dropping (Switch blackhole) Packet injecting üthese attacks affects the entire network! Protection of SDN data plane is more important than traditional networks! [1],[2] [1] Dhawan, M., Poddar, R., Kshiteej, M., & Vijay, M. (2015). SPHINX: Detecting Security Attacks in Software-Defined Networks. In Proceedings 2015 Network and Distributed System Security Symposium (pp. 8 11). [2] Shaghaghi, A., Kaafar, M. A., & Jha, S. (2017). WedgeTail: An Intrusion Prevention System for the Data Plane of Software Defined Networks. In Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security - ASIA CCS 17 (pp ). New York, New York, USA: ACM Press.

6 6 Related Work Byte consistency check (SPHINX [M.Dhawan et al. / NDSS 15] ) Compare the entire view of network (Flow graph) with the amount of packet transfer Construct flow graph with collected route information (FLOW_MOD messages) and calculate expected path Controller Controller Application Route info. (FLOW_MOD) SPHINX Statistics data(stats_reply): asynchronous message from switches respond to STATS_REQUEST ü Depends on the timing of STATS_REQUEST message received Issue Verification accuracy depends on the controller performance Host OpenFlow switches Host

7 7 Background Technology Time4 [T.Mizrahi et al./infocom 16] Schedule network updating at the same time with Scheduled Bundle Utilizes IEEE1588 Precision Time Protocol (PTP) Enables nanosecond order time synchronization using hardware-timestamping enabled NIC module. Without depend on the controller performance It is scalable! Controller Our Challenge Solve the issue of Byte consistency check with statistics gathering at the same time Host Time-synchronized OpenFlow Switches Host

8 8 Our method Forwarding State Verification with Timed Statistics Gathering Schedule the timing of statistics gathering at the same time to each switches Synchronize clocks between Verifier and OpenFlow switches üenables to verify without depending on the performance of the controller Route information (FLOW_MOD) Controller Controller Application Performing verification without depend on the performance of the controller Verifier Statistics (STATS_REPLY) Get actual transfer statistics of all switches at the same time with Scheduled Bundle. Host Time synchronized OpenFlow switches Host

9 9 Assumption The controller applications are trusted Majority of switches are legitimate These assumption similar to SPHINX Focus on the data plane security Knows reliable physical topology Control-plane security is well studied by other work [3] Trusted controller application Controller Controller Application Verifier Knows reliable physical topology Majority of switches are legitimate (some compromised switches included) Host Time synchronized OpenFlow switches Host [3] S. Khan, A. Gani, A. W. Abdul Wahab, M. Guizani, and M. K. Khan, "Topology Discovery in Software Defined Networks: Threats, Taxonomy, and State-of-the-Art," IEEE Communications Surveys & Tutorials, vol. 19, no. 1, pp , 2017.

10 10 Sequence of Verification 1 SPHINX (Existing solution) Calculate current path Proposal Method 2 Gather statistics Gather statistics at the same time 3 Verify with the moving average of the statistics (Similarity Index) Verify transfer state consistency Verify with the statistics gathered at the same time

11 11 1. Calculate Current Path Uses a flow graph (network assumed by a trusted controller) and physical topology information Uses match fields and instruction: src/dst MAC address, src/dst IP address, and in/out port Controller Controller Application Route information (FLOW_MOD) Verifier Calculates current path using physical topology information and FLOW_MOD messages h1 h2 h1 Time synchronized OpenFlow switches h2

12 12 2. Statistics Gathering with Scheduled Bundle Scheduled Bundle [T.Mizrahi et al. / INFOCOM 16][OpenFlow 1.5] A generic method to schedule any OpenFlow message Included in OpenFlow 1.5 üschedules STATS_REQUEST message with Scheduled Bundle to each switches Enables gathering statistics at the same time Mainly uses byte_cnt and match field Uses the moving average of last four statistics in verification Eliminates the effects of switch performance Send Bundle Commit contains schedule execution time TS At TS, processes STATS_REQUEST message

13 13 3. Verification (1) Verify each traffic flow with two points of view Whether the flow statistics of switches included in the current path reports similar value between each switches The margin calculate by threshold (input value) Detects malicious packet delaying and packet dropping Whether the flow statistics of switches not included in the current path reports zero Detects malicious packet injecting and misrouting

14 14 3. Verification (2) Difference of SPHINX: Reference value of verification SPHINX: The average of Similarity Index each switches (Similarity Index: Moving average of byte transfer statistics) Our method: The statistics of the verification already passed switches Considers the difference of the statistics values which occurs by propagation delay

15 15 Example of our method s algorithm behavior Case of all switches are legitimate: s1 s2 s3 OK ByteDiff = 100 Compare ByteDiff = 98 Compare ByteDiff = 96 Case of switch s2 is compromised switch (perform blackhole) : Detect attacks by honest downstream switch s1 s2 s3 ByteDiff = 100 Compare ByteDiff = 98 Compare ByteDiff = 96 Wrong Raise an alarm

16 16 Experiment Environment Emulated Mininet network Use minimal topology (linear topology, 3 switches and 3 hosts) Separated the controller application host and the Mininet host To mitigate the impact of resource conflicting Controller Same host to emulate time synchronization with accurate time Time synchronized OpenFlow switches Controller Application Verifier s1 s2 s3 Floodlight v1.1 OpenFlow Proxy (implemented our method) ofsoftswitch13_ext-340 h1 h2 h3

17 17 Experiments Scheduling Accuracy Measured the accuracy of scheduling emulated testbed (Mininet) False-Positive Rate Measured the probability of detecting normal TCP traffic as attacks Check the impact to verification when controller performance occurs degradation. False-Negative Rate Measured the probability of the lack of genuine alarm Check the impact to verification when controller performance occurs degradation. Simulated the variation of the controller performance by delay (d) Insert before sending STATS_REQUEST from the verifier.

18 NTP synchronization accuracy millisecond order Scheduling error in NTP synchronization environment max millisecond order 18 Scheduling Accuracy of our testbed Measured the accuracy of scheduling emulated testbed (Mininet) Measured the difference between actual execution time and scheduled execution time Less than 0.3 millisecond in the 90 percentiles at all switches This environment is sufficient to evaluate our method

19 19 False-Positive Rate: SPHINX vs our method Generate TCP flows from h1 to h3 with iperf Simulated the variation of the controller performance by delay (d) Occurs false-positive when threshold (the margin of statistics value) decrease Controller Controller Application Time synchronized OpenFlow switches Verifier s1 s2 s3 TCP Flow from h1 to h3 h1 h2 h3

20 20 False-Positive Rate: SPHINX vs our method Result SPHINX s False-Positive Rate Our method s False-Positive Rate increases false alarms when controller performance degrade Not increase false alarms! Our method without depend on controller performance!

21 21 False-Negative Rate: SPHINX vs our method Generate TCP flows from h1 to h3 with iperf Emulate malicious behaviors by compromised switches performed packet drop on s2-s3 link with link loss rates(2%, 4%, 6%) Occurs false-negative when threshold (the margin of byte count value) increase Controller Controller Application Time synchronized OpenFlow switches Verifier s1 s2 s3 Link loss (2%, 4%, 6%) (emulated malicious behavior) TCP Flow from h1 to h3 h1 h2 h3

22 22 False-Negative Rate: SPHINX vs our method Result 2% loss 4% loss 6% loss 2% loss 4% loss 6% loss Delay d = 0 Our method false-negative rate is not much different from SPHINX. Delay d = 10 (From FP rate experiment) Our method can set lower threshold than SPHINX the false-negative rate equivalent to SPHINX by tuning threshold.

23 23 Discussion: Future Work Evaluates in real-world environment Reduce the statistics gathering overhead of Scheduled Bundle Improves Scheduled Bundle to enable periodical execution scheduling Distributed Controller environment (such as ONOS) Improves the method to consider a link specific delay

24 24 Conclusion Background Protection of SDN data plane is more important than traditional networks SPHINX s verification accuracy depends on the controller performance Proposal method: Forwarding state verification with scheduled statistics gathering Key idea: Schedule the timing of statistics gathering at the same time to each switches Detects attacks by compromised switches without depending on the controller performance Experiment Result Confirm the false positive rate of our method is lower than SPHINX even if the controller performance decrease Thank you for listening!