1 / 36

Contextual, Flow-Based Access Control with Scalable Host-based SDN Techniques

Contextual, Flow-Based Access Control with Scalable Host-based SDN Techniques.

paulkelly
Download Presentation

Contextual, Flow-Based Access Control with Scalable Host-based SDN Techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Contextual, Flow-Based Access Control withScalable Host-based SDN Techniques [Taylor-INFOCOM16] Taylor, Curtis R., Douglas C. MacFarland, Doran R. Smestad, and Craig A. Shue. "Contextual, Flow-Based Access Control with Scalable Host-based SDN Techniques.", IEEE International Conference on Computer Communications (INFOCOM) 2016. Present by: WenzhiCai

  2. OUTLINE • Introduction • SDN • OpenFlow • Challenges of SDN Approach • Specific technical problems • Description • Threat Model • Approach • Contextual Policies • Evaluation • Criticism

  3. INTRODUCATION

  4. Travel to another country! Hello world!

  5. Traditional systems: Blind to intra-subnet traffic • Recent innovations: • OpenFlow (2010) • Software-defined networking (SDN) (2011)

  6. Overview: The SDN controller defines the data flows that occur in the SDN Data Plane. If the controller allows a flow, it compute a route for the flow to take, and adds an entry for that flow. Communication between the controller and the switches uses a standardized protocol and API. Requirements of practical implementation: A common logical architecture in all switches, routers, and other network devices managed by an SDN controller A standard, secure protocol between the SDN controller and the network devices

  7. OpenFlow Network • Controller • Manages one or more switch via OpenFlow channel • Uses OpenFlow protocol to communicate with a OpenFlow Switch • Responsible for programming various tables in the OpenFlow Switch • Single switch can be managed by more than on controller for load balancing or redundancy purpose • FlowVisor • Virtualize network • OpenFlow Switch • FlowTable • Secure Channel • OpenFlow Protocol

  8. OpenFlowProtocol (Southbound) • Allows control (controller) and data(switches) to be split up • Switches send information about flows to control plane • Control plane sends instructions for handling flows to switches • Enables the controller perform add, update, and delete actions in the flow table • Implemented on top of SLL or TLS • Secure OpenFlow channel • Support 3 types of messages • Asynchronous Messages • Packet-In Message • Flow Removed Message • Controller-to-Switch Messages • Multi-part, statistics gathering • Symmetric Messages • Hello messages • Echo request and reply messages • Experimenter message

  9. SDN & OpenFlow • SDNs, implemented using OpenFlow, provide a powerful, vendor-independent approach to managing complex networks with dynamic demands. • SDN with OpenFlowprotocol allows a centralized controller to learn each time a new flow is created • The software-defined network can continue to use many of the useful network technologies already in place, such as virtual LANs and an MPLS infrastructure. • SDNs and OpenFlow are likely to become commonplace in large carrier networks, cloud infrastructures, and other networks that support the use of big data

  10. Challenges of SDN APPROACH • Data Plane Scalability concerns • Limit Visibility contextual into end-host • Malware Approach • OpenFlowSwitch Limitation • Handling new flows • Varies into 150 and 750 new flows per second • Slow speed memory reduce new flow • Lead to performance bottleneck, Denial of Services and user-level adversaries

  11. specific TECHNICAL PROBELMS • How can we scalable obtain flow-level information for all network traffic? • How can we provide network operator with details context surrounding each network flow?

  12. APPROACH DESCRIPTION

  13. Contributions • Scalable, fine grained flow-base access control • Leveraging distribute computing power of the end host • Allow host to apply fine-grain rules • Hardware to apply coarse-grain rules • Take OpenFlowagent functionality into end-host • Host Context for all network flows • Allow operator to develop detail policies for flow authorisation

  14. Threat model: User-Level Adversary • Key assumptions: • Trusted Operating System • No physical attacks • Focus on devices can be modified by an IT staff • Full flow-management compatibility

  15. APPROACH overview • Host-Based Approach • Implementation: • Ubuntu Linux Operating System • Network layer and above • Features: • Flow-based controls and context • A capability to arbitrarily route traffic through proxies, IDSes, and other middleboxes • A modular design • Explicit notification to network controllers when a flow ends, allowing accurate real-time network flow insight • Optimal traffic filtering at the source host to avoid network overheads • Avoids the need for kernel or application modifications by using established kernel features

  16. Approach overview • Host Agent: Intercepting Packets • Marking Features • Mark or unmark packets • Drop mark • Host Agent: Extraction Operating Context • Module Design and Plug-ins • SDN Controller

  17. Application Layer Travel to another country! Control Plane Hello world! A flow SDN Agent Packets

  18. 1. Host agent: intercepting packets • The iptables firewall: mark or unmark feature • netfilter queue: intercept unmarked packets • Upadateiptables: create a ”drop mark” used to discard a flow • SDN Agent: analyzes the intercepted packet and determines the context (step 3-4) • SDN Agent: transmits a message to the SDN controller and requests instructions (step 5) • SDN Controller: issue rules (step 6) • SDN Agent: install appropriate NAT, firewall, routing, forwarding rules; (step 7) • iptables: update the marking to indicate the flow is authorized • SDN Agent: signal netfilter_queue for transmission • netfilter_queue: release the packet (step 8) • Routing Policy DB: select routing table • Two communication parties • The initial packet will not match any existing approval kernel flow

  19. 2. Host AGENT: EXTRATING OPERATINg CONTEXT • Plugins: provide context • Netfilter_queue: allows the Agent to determine user name and group associated with the extracted packet • Socket: gather data (Isof: process ID) • /proc: executable path associated with the process and the command line arguments • Examine the executable path • Collect similar information about the process’s ancestors

  20. 3. SDN CONTROLLER Northbound • “BRAINS” of the network • Manage flow control to the switches ‘below’ • Manage the applications and business logical ‘above’ • Implementation: a Python Controller • Future: make implementation enhancements Southbound

  21. contextual POLICIES Policies: Allow Administrative Process Deny All User-Installed Programs Default Allow Specify the high-level policies: • Contextual languages • POL-EH • Flow-based security Language (FSL) • Flow-based Management Language • Summary: • Allow administrative background and daemon processes. • Ensure that only process from administrator-installed sources can use the network. • Act as a template for additional organization constraints

  22. evaluation

  23. Evaluation overview • Implementation: In a small network of virtual machines (VMs) • Preparations • VMs: Runs on a single server with 16 cores operating at 2.8 GHz and 64 GBytes running with a KVM hypervisor • Network Controller: Allocated two cores and 2048 MBytes of RAM • Each Client system: Allocated a single core & 512 Mbytes of RAM • All machines: Ubuntu 14.04 Server as Operating Systems • Each host: Preinstalled iptables; Load the conntrackkernel module to allow fine-grained manipulation • Three aspects • The agent instrumentation • The data plane and controller scalability • The effectiveness of the security policy

  24. Evaluation - HOST AGENT performance • Timing experiment: • The latency overhead with elevating a new flow to the controller • Record the clock timestamp for: • A~B: Initial Interception • B~C: Obtain Host Context • C~F: Evaluation to Controller • D~E: Controller Decision • F~G: Marking • G~H: Re-queuing • Overall End-to-end: A~H • 1000 TCP connections

  25. Overall SDN Agent: a median under 17ms • Minimal time • Communication between kernel and agent via netfilter_queue • > 100ms delay • Gathering of host context • Roundtrip to the controller • Packet marking approach

  26. Optimizations for delay: • Host context collection can be parallelized • Communication protocol can be greatly simplified • Packet marking can use a more efficient netfilter-conntrackcall • The use of a compiled language would greatly improve performance

  27. Evaluation- data PALNE & CONTROLLER scalability Scalability experiment • Number of hosts: 2, 4, 6, 8, 10, 12, 14 & 28 hosts • Each host sequentially creates 1,000 new TCP flows to another host • Sender calculated the RTT ( Round trip times) • Record the number of new created flows per second for each host

  28. Median RRT: Approximately double the Overall End-to-end result which is 16.7ms • 350 flows per second (25 *14) • All the data plane flow state is stored at the hosts • From the timing results: The controller can handle around 200,000 new flows per second by spending 0.005 ms on each packet

  29. EVALUATION- POLICY ENHANCEMENT ON SECURITY Simulated Linux Malware (n00bRAT) experiment: • Test a case where a user on a host receives and runs the malware • Perform a browser-based attack using Metasploit and launch the malware using the compromised browser Results: The malware is denied network access Conclusion: • The policy will allow the adversary to establish a connection to download the malware to the user’s machine • If the adversary launch the malware, the policy denies the malware any network access.

  30. CRITICISM

  31. Criticism • Approach can interact with legacy devices (BYOD). • Connecting Embedded devices like printer. • Isolate VLAN with physical proxy to avoid bottlenecks. • Approach are compatible with non Linux hosts. • Apple’s Mac OS X and Microsoft’s Windows OS • OS X’s firewall, pf, is based upon OpenBSD firewall implementation. • Devices or OS unable to support a native host agent: • A “bump-in-the-wire” solution • Fine grained policies and host context enable by default. • Allow organisation to flexibility in respond to a compromised • Provides Robust control include intra-subnet traffic with less disrupt to network

  32. THANKS!

More Related