Contextual, Flow-Based Access Control with - PowerPoint Presentation

Slide1

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: Wenzhi Cai

1Slide2

OUTLINEIntroduction

SDNOpenFlowChallenges of SDN ApproachSpecific technical problemsDescriptionThreat ModelApproachContextual PoliciesEvaluation

Criticism

2Slide3

INTRODUCATIONSlide4

4Slide5

5

Travel

to another country!

Hello world! Slide6

Traditional systems: Blind to intra-subnet trafficRecent innovations:

OpenFlow (2010) Software-defined networking (SDN) (2011)6Slide7

7Slide8

8

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 controllerA standard, secure protocol between the SDN controller and the network devices Slide9

OpenFlow NetworkControllerManages one or more switch via OpenFlow channelUses OpenFlow protocol to communicate with a

OpenFlow SwitchResponsible for programming various tables in the OpenFlow SwitchSingle switch can be managed by more than on controller for load balancing or redundancy purposeFlowVisorVirtualize networkOpenFlow SwitchFlowTableSecure ChannelOpenFlow Protocol9Slide10

OpenFlow Protocol (Southbound)Allows control (controller) and data(switches) to be split upSwitches send information about flows to control plane

Control plane sends instructions for handling flows to switchesEnables the controller perform add, update, and delete actions in the flow table Implemented on top of SLL or TLSSecure OpenFlow channelSupport 3 types of messages Asynchronous MessagesPacket-In MessageFlow Removed MessageController-to-Switch MessagesMulti-part, statistics gatheringSymmetric MessagesHello messages

Echo request and reply messages

Experimenter message

10Slide11

SDN & OpenFlowSDNs, implemented using OpenFlow, provide a powerful, vendor-independent approach to managing complex networks with dynamic demands. SDN with

OpenFlow protocol allows a centralized controller to learn each time a new flow is createdThe 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 data11Slide12

Challenges of SDN APPROACHData Plane Scalability concernsLimit Visibility contextual into end-hostMalware Approach

OpenFlow Switch LimitationHandling new flowsVaries into 150 and 750 new flows per secondSlow speed memory reduce new flowLead to performance bottleneck, Denial of Services and user-level adversaries12Slide13

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

13Slide14

APPROACH DESCRIPTIONSlide15

ContributionsScalable, fine grained flow-base access controlLeveraging distribute computing power of the end host

Allow host to apply fine-grain rulesHardware to apply coarse-grain rulesTake OpenFlow agent functionality into end-hostHost Context for all network flowsAllow operator to develop detail policies for flow authorisation

15Slide16

Threat model:Key assumptions: Trusted Operating SystemNo physical attacksFocus on devices can be modified by an IT staff

Full flow-management compatibility16User-Level AdversarySlide17

APPROACH overviewHost-Based ApproachImplementation: Ubuntu Linux Operating SystemNetwork layer and above

Features:Flow-based controls and contextA capability to arbitrarily route traffic through proxies, IDSes, and other middleboxesA modular designExplicit notification to network controllers when a flow ends, allowing accurate real-time network flow insightOptimal traffic filtering at the source host to avoid network overheadsAvoids the need for kernel or application modifications by using established kernel features17Slide18

Approach overviewHost Agent: Intercepting Packets

Marking FeaturesMark or unmark packetsDrop markHost Agent: Extraction Operating ContextModule Design and Plug-insSDN Controller18Slide19

19Slide20

20

Travel to

another country!

Packets

A flow

SDN Agent

Control Plane

Application Layer

Hello world!

Slide21

1. Host agent: intercepting packetsT

he iptables firewall: mark or unmark featurenetfilter queue: intercept unmarked packets Upadate iptables: create a ”drop mark” used to discard a flowSDN 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 transmissionnetfilter_queue

:

release the packet

(step 8)

Routing Policy DB

: select routing table

21

Two communication parties

The initial packet will not match any existing approval kernel flowSlide22

2. Host AGENT: EXTRATING OPERATINg CONTEXT

Plugins: provide contextNetfilter_queue: allows the Agent to determine user name and group associated with the extracted packetSocket: gather data (Isof: process ID)/proc: executable path associated with the process and the command line argumentsExamine the executable path Collect similar information about the process’s ancestors22Slide23

3. SDN CONTROLLER“BRAINS” of the networkManage flow control to the switches ‘below’Manage the applications and business logical ‘

above’Implementation: a Python ControllerFuture: make implementation enhancements 23Northbound Southbound Slide24

contextual POLICIESSpecify the high-level policies: Contextual languagesPOL-EHFlow-based security Language (FSL)

Flow-based Management Language24Summary: 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 constraintsPolicies:

Allow Administrative

Process

Deny All User-Installed Programs

Default AllowSlide25

evaluationSlide26

Evaluation overviewImplementation: In a small network of virtual machines (VMs)PreparationsVMs: Runs on a single server with 16 cores operating at 2.8 GHz and 64 GBytes

running with a KVM hypervisorNetwork Controller: Allocated two cores and 2048 MBytes of RAMEach Client system: Allocated a single core & 512 Mbytes of RAMAll machines: Ubuntu 14.04 Server as Operating SystemsEach host: Preinstalled iptables; Load the conntrack kernel module to allow fine-grained manipulationThree aspectsThe agent instrumentationThe data plane and controller scalabilityThe effectiveness of the security policy

26Slide27

Evaluation - HOST AGENT performance27

Timing experiment: The latency overhead with elevating a new flow to the controller Record the clock timestamp for: A~B: Initial InterceptionB~C: Obtain Host ContextC~F: Evaluation to ControllerD~E: Controller DecisionF~G: MarkingG~H: Re-queuingOverall End-to-end: A~H1000 TCP connectionsSlide28

28

Overall SDN Agent: a median under 17msMinimal timeCommunication between kernel and agent via netfilter_queue> 100ms delayGathering of host contextRoundtrip to the controllerPacket marking approachSlide29

Optimizations for delay: Host context collection can be parallelized Communication protocol can be greatly simplifiedPacket marking can use a more efficient netfilter-conntrack call The use of a compiled language would greatly improve performance

29Slide30

Evaluation- data PALNE & CONTROLLER scalability Scalability experimentNumber of hosts: 2, 4, 6, 8, 10, 12, 14 & 28 hostsEach 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 30Slide31

31

Median RRT: Approximately double the Overall End-to-end result which is 16.7ms350 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 packetSlide32

EVALUATION- POLICY ENHANCEMENT ON SECURITYSimulated Linux Malware (n00bRAT) experiment:

Test a case where a user on a host receives and runs the malwarePerform a browser-based attack using Metasploit and launch the malware using the compromised browserResults: 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 machineIf the adversary launch the malware, the policy denies the malware any network access.

32Slide33

CRITICISMSlide34

CriticismApproach 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 OSOS 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” solutionFine grained policies and host context enable by default.Allow organisation to flexibility in respond to a compromisedProvides Robust control include intra-subnet traffic with less disrupt to network34Slide35

35Reviews

Background knowledgeSDN & OpenFlow Research problems

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?

Proposed

a

pproach

Scalable flow-based access control

: Host Agent- Intercepting packets (mark/unmark feature of

iptable

)

Contextual

(fine-grained):

Host Agent- Context extraction ( Socket

 plugins)

Security

enhancement:

Contextual polices

Evaluation

Timing experiment – Host agent performance

Scalability experiment – data and control plane

Simulated malware experiment – contextual policies

Conclusion:

Scalable flow base monitoring

Reuse existing network infrastructure

Easily mitigate traffic floods

Logically centralize access controlSlide36

THANKS!

36Slide37

OpenFlowConnection terminations: The controller doesn’t directly learn when a connection endsTermination time: timeoutsApproximate

Proposed ApproachConnection terminations: Host Agent can inform the controller about connection terminationsUse netfilter-conntrack library to intercept the CONTRACK_DESTROY kernel event Termination time: netfilter-cttimeoutRealtime37

Compare Slide38

A. Partial deployment 3 scenarios: Both hosts deploy: full managementNeither host deploys: degrade to a traditional network infrastructure Having a single host participating in a flow: the host can enforce any policies set forth by the controller

Approach allows organizations to use standard software deployment toolsApproach allows organizations to deploy the approach to subsets of the organization by functionsApproach can also interact with legacy devices (BYOD)Connecting Embedded devices like printer.Isolate VLAN with physical proxy to avoid bottlenecks38Slide39

b. COMPATIBILITY WITH nON-lINUX hostCan be applied on other OS, such as Apple’s Mac OS X and Microsoft’s Windows OSOS X’s firewall, pf, is based upon OpenBSD firewall implementation.

BSD provide a special socket interface to intercept packets for the host agentFor devices or OS unable to support a native host agent:A “bump-in-the-wire” solution39Slide40

C. Potential for Network security policy Fine grained policies and host context enable by default.Allow organisation to flexibility in respond to a compromisedProvides Robust control include intra-subnet traffic with less disrupt to network

40Slide41

Related workSlide42

Related Work - OpenFlow Fine-Grained Flow ScalabilityCommodity OpenFlow switches are not built to handle the number of fine-grained flows organizations

Some OpenFlow switches can support between 750 and 2,000 flowsPoor performance of OpenFlow hardware switches with fine grained flowsWang et al: A tunneling solution 42Slide43

Related Work – Extracting Context from End-HostsEthane ( Early SDN Implementation)A switch-based SDN approach, like

OpenFlowLacks information from the end-hosts HoNeProvides process attribution by correlating network traffic to processesLacks Centralized coordination and doesn’t support arbitrary host context or embrace the SDN paradigmVirtual machines and TPMs (Dixon et al)Allow network administrators to securely push network management to the end-hostLack situational awareness inherent to OpenFlow based SDNsAssayer’s approach (Parro et al)Uses end-host TPM capabilitiesParticipating systems push policies to off-path verifiers

Does not follow the

OpenFlow

SDN modelDoes not scale when attestation is required on a per packed

A revision to the

ident

protocol

basis

Allow a remote system to query for details

Ident++, work under the

OpenFlow

protocol

43Slide44

Learning from related worksOpenFlow Fine-Grained Flow Scalability: Uses SDN agents in host software to achieve scalabilityDiffers in their SDN agent runs within the host operating system itself, rather than in a hypervisor

1) Obtain detailed context about the host’s environment2) Support end-hosts that do not use virtualizationExtracting Context from End-HostsShares the goal of fusing end-host information with network control with ident++Take a host-based approach to address scalabilityUse a OS solution and a bump-in-the-wire implementation for evaluation44