PivotWall: Combining SDN and Host Context to Defend Against Stepping Stone Attacks.

(1)

ABSTRACT

VERMA, AKASH. PivotWall: Combining SDN and Host Context to Defend Against Stepping Stone Attacks. (Under the direction of William Enck.)

Advanced Persistent Threat (APT) attackers often relay their attacks through a series of

intermediate compromised hosts. By laterally pivoting through stepping stones, attackers

can bypass typical enterprise defenses to target critical internal servers. Existing techniques

to detect stepping stone attacks both - 1) perform poorly when attackers obfuscate their

traffic to evade detection, and, 2) fail to address the different maneuvers, attributes and

purposes of stepping stone models. To address these shortcomings, we present PivotWall, a

cooperative defense model that leverages a Software-Defined Networking (SDN) controller

and a host agent. Through cooperative provenance propagation (tainting) of network traffic and monitoring file access, network handles, and process interactions on the host, we

provide a model that effectively detects and prevents stepping stone attacks. We implement

our model as a prototype SDN controller application and a host application. We evaluate

the attack coverage, network scalability, host performance, and accuracy of our prototype

in both a scalable emulation and a realistic lab environment. Our experiments demonstrate

that PivotWall detects a wide array of stepping stone attacks with an acceptable low rate of

false positives, low performance overhead, and has the ability to scale to support enterprise

networks. PivotWall successfully leverages the capabilities of the SDN architecture, and, in

(2)

(3)

PivotWall: Combining SDN and Host Context to Defend Against Stepping Stone Attacks

by Akash Verma

A thesis submitted to the Graduate Faculty of North Carolina State University

in partial fulfillment of the requirements for the Degree of

Master of Science

Computer Science

Raleigh, North Carolina

2017

APPROVED BY:

Douglas Reeves Alexandros Kapravelos

William Enck

(4)

DEDICATION

(5)

BIOGRAPHY

The author completed his Bachelors degree in Information Systems from Birla Institute

of Technology and Science, Pilani, India. He worked for a couple of years at Yahoo and

(6)

ACKNOWLEDGEMENTS

I would like to thank my advisor, Dr.William Enck, for being a great mentor and helping

me throughout the duration of my thesis research in many different ways. He kept me

motivated and was always available to guide me in the right direction. This thesis would not

have been possible if it were not for his help and guidance. I also thank Dr. Douglas Reeves

and Dr. Alexandros Kapravelos for taking the time to be on my committee, and for being

supportive of my research. I thank Terrence O’Connor for being a constant contributor to this research and providing many valuable suggestions. I also thank Micah Bushouse,

Adwait Nadkarni, Luke Deshotels, Isaac Polinsky, Ben Andow, and other members of the

WSPR lab for their many valuable inputs to this work.

Finally, I thank my family and my friends for being supportive of my decisions and

(7)

LIST OF TABLES

Table 2.1 Characteristics of Stepping Stone Attacks . . . 6

Table 6.1 Coverage of Attacks . . . 36

Table 6.2 Network Scalability of PivotWall . . . 39

Table 6.3 Benchmark Tests for Host Performance Evaluation . . . 40

Table 6.4 UnixBench System Benchmark Index Scores (1 and 4 cores) . . . 41

Table 6.5 Benchmark Tests Results . . . 41

(10)

LIST OF FIGURES

Figure 2.1 SDN architecture overview with various components . . . 10

Figure 3.1 Stepping Stone Attack Motivating Scenario . . . 14

Figure 4.1 Network Monitoring and Taint Propagation . . . 22

Figure 4.2 Host Agent Monitoring and Taint Propagation . . . 25

Figure 4.3 Design of Host Agent . . . 26

Figure 4.4 Provenance Discovery . . . 30

Figure 5.1 SDN App Internals . . . 32

Figure 6.1 Host Agent Attack Detection of Socat . . . 37

Figure 6.2 Host Agent Detection of Meterpreter/reverse_http . . . 38

Figure 6.3 Hospital Data Loss Scenario . . . 42

(11)

CHAPTER

1 INTRODUCTION

Software-Defined Networking (SDN) offers a new perspective to address complex

net-work attacks. The central location of a netnet-work controller eliminates the need for a

dis-tributed monitoring infrastructure. Security applications running on the SDN controller can transparently monitor the holistic view of the network with minimal performance

over-head. An SDN security application can offer fine-grained network management[Shi13a; Shi13b], interaction with legacy network hardware[Sko13], elasticity[LD15; Aba14]and offline processing[Heo14]to handle complex threat monitoring and detection. Further, an SDN-based solution can uniquely respond to network attacks by reactively hiding critical

resources[Son14], implementing moving target defenses [MS15; Kam14], black-holing traffic to prevent compromise[Sko13], transparently moving targets[Jaf12], or rate throt-tling[Wan15]until a threat can be confirmed. Previous papers have also investigated the use of SDN to handle complex attacks such as distributed denial of service attacks[Wan15].

While the SDN maintains a holistic network-visibility, it lacks the context of host. For

ex-ample, an SDN application cannot determine with assurance if a host-inbound connection

(12)

applications and causes any purely SDN-based security applications to speculate on host activities, which is a significant problem in identifying stepping stone attacks. Stepping

stone attacks abuse internal network trust to allow an attacker to laterally pivot through the

internal network and bypass security controls. Typical methods for stepping stone attacks

include installation of remote access toolkits, port-forwarding, abusing benign services

such as SSH, or using covert methods to exfiltrate data (HTTP beaconing[Mud16], covert TCP[ML05], or DNS tunnelling[Ver16]).

In this work, we aim at leveraging the holistic network information present at the

SDN controller and combine it somehow with the host execution context. Since the SDN

controller can monitor all the flows, the addition of host context will help solve the problem of identifying the flows that propagate correlated data across the whole network or a part

of it. This insight leads to the following thesis statement:

The capabilities of Software-Defined Networking can be used to combine the network context with the host context to detect and mitigate against stepping stone attacks.

Previous solutions, such as network-flow watermarking[Hou09]and packet timing mon-itoring[WR03; Wan05a; Wan05b], do not incorporate host context and therefore encounter fundamental limitations in accurately identifying stepping stone attacks. However, an

at-tacker can evade these approaches[Kiy08; Luo11; Pen06]by introducing delay, chaff, and packet re-packetization[Don02; Pen05; Pos81; Pyu12]. Additionally, the Store-and-forward attack model, introduced by Coskun and Memom[CM07], also presents a challenge to detecting stepping stone attacks. In store-and-forward, an attacker can store or delay data

at a compromised intermediate host for an indefinite period of time. Many real-world

applications that enable stepping stone attacks (e.g.,netcat) use the store-and-forward mechanism to exfiltrate data by writing the entire data to the intermediate host before

relaying it.

To address the limitations of previous methods for detecting stepping stone attacks, we

propose PivotWall, a cooperative defense against stepping stone attacks that uses

prop-agation (tainting) between hosts as well as within a host. PivotWall builds on the holistic network-visibility of SDN. Our design embodies two key observations: (1) a host-agent can

increase the SDN application?s tracking precision by identifying flows between processes,

file, and network connections; and (2) stepping stone attacks that rely on an active

com-mand and control channel can by identified by using the protected host (e.g., git server) as

(13)

enterprise network, which may lead to taint explosion. We evaluate PivotWall using both scalable emulation and a lab environment and show that our implementation observes only

0.69% false positives while incurring less than 9.93% overhead on the host and a maximum

of 18.27% overhead on the SDN controller.

The goal of PivotWall is to provide an efficient means of detecting stepping stone attacks

that explicitly target critical or vulnerable hosts (e.g., SCADA, SCM, and IoT). By considering

the execution context on the intermediate host and combining that knowledge with the

complete network-visibility, PivotWall presents a system capable of improved detection of

such attacks. Further, by monitoring the execution context of the host, PivotWall minimizes

the false positives associated with methods that lack the execution context of the host. Our work makes the following contributions:

• We propose the concept of an SDN propagation solution that accurately performs

at-tack flow-tracking along with the host execution context. We argue that a cooperative

defense strategy combining the benefits of an SDN controller and a host agent can

accurately and cost-effectively detect attacks against data loss and compromise to

critical and vulnerable hosts. Through this approach, our solution efficiently reacts

to threats across the entire network.

• We implement a prototype and evaluate it against actual attack tools that use different

techniques for attacks in the presence of realistic benign traffic. Our results show

that PivotWall can accurately detect stepping stone attacks with minimal impact on

network throughput, performance overhead of the host, or excessive logging.

• We perform case studies by replicating two different stepping stone attacks from

real world on a realistic network setup and evaluate and discuss the performance of

PivotWall in these scenarios.

1.1 Contributions to This Project

This work is a joint effort by TJ O’Connor and Akash Verma. The high level idea for the

project was conceived by TJ O’Connor who was then joined by Akash Verma. They together studied the problem in detail to outline the characterization of stepping stone attacks and

(14)

The design of PivotWall was a joint effort by TJ and Akash with the initial ideas being conceived by TJ and then brought into the final shape together with the help of Akash. The

design and implementation of the SDN app to perform the network level taint management

was done by Akash while that of the host agent that performs host based data provenance

was done by TJ. TJ also designed the algorithm to create a provenance graph of the attack

using information from the network as well the host level provenance logs. The evaluation

was a joint effort with Akash performing all the experiments aimed at evaluating the host

performance and performing the case studies aimed at evaluating the accuracy of PivotWall.

TJ performed all the experiments aimed at network performance evaluation and detection

(15)

CHAPTER

2 BACKGROUND

The first section of this chapter introduces stepping stone attacks and classifies the them

into different categories based on certain characteristics that we identified after analysing

the anatomy of different stepping stone attacks. The second section of this chapter in-troduces Software Defined Networking (SDN) which is new paradigm in networking and

provides various features and flexibilities that are not easily found in traditional networks.

We leverage a few of these novel features of SDN in our approach and have designed our

solution which can be deployed in an SDN environment.

2.1 Stepping Stone Attacks

Traditional research has mostly looked at stepping stone attacks as interactive attacks where the attackers maintain an active command and control channel from a host on the external

network. These attacks mostly comprised of attackers getting remote access to one or more

internal hosts and creating an attack chain using by sequentially logging onto the next host

(16)

Table 2.1 Characteristics of Stepping Stone Attacks

Characteristic Sub-Characteristic Value (1) Channel Attribute (1a) Channel Encryption (Yes, No)

(1b) Active vs. Passive (Active,Passive) (1c) Channel Direction (Ingress, Egress) (2) Attacker Maneuver (2a) Legitimate Access (Yes, No)

(2b) Established Foothold (Yes, No) (2c) Internal Forwarder (Yes, No) (3) Attacker Purpose (3a) Confidentiality (Yes, No)

(3b) Integrity (Yes, No)

(3c) Availability (Yes, No)

sessions. In such a case, the attacker also performs the attack steps within a maximum

tolerable delay as the attack only lasts till the session id active. Prior work has looked as

how active flow watermarking and flow correlation can be used to detect such stepping

stone attacks. The attackers, however, keep trying to change the way they carry out such

attacks to evade detection and this has lead to various new and different ways of carrying

out the stepping stone attacks. Not all of them require active remote sessions amongst the

hosts and some even use multiple different flows to carry out the attack steps.

The following sections presents a characterization of stepping stone[Shu11]attacks which also depicted in Table 2.1. This classification of the stepping stone attacks is based

on three characteristics ofmaneuver, channel attributesandpurposeof the attacker. This classification provides the justification for the design presented in Section 4. With an

understanding of the characteristics of stepping stone attacks, this section concludes by

describing the threat model and assumptions for our approach.

2.1.1 Stepping Stone Channel Attributes

Previous methods for detecting stepping stone attacks often theorize methods for

determin-ing correlation between different network connections. These models have some drawbacks

such as 1) sensor placement and selection[Tan06], 2) resulting in an unacceptable rate of false positives[Shu11], and, 3) failure to detect attacks that use either store-and-forward relay nodes[CM07]or split-relay nodes. We examine the attributes of the stepping stone attack channel to understand the methodology behind the PivotWall design.

(17)

packet contents. To examine an encrypted channel, an intrusion detection system must intercept and arguably weaken the overall security of the network to examine the contents

of a packet. As such, attackers commonly encrypt the channel of an intermediate attack

to bypass content inspection. As an example,cryptcat [Joh15]is anetcat[Gia13]fork that encrypts the attacker channel using thetwofishsymmetric key block cipher. The Poison Ivy toolkit[Bin11], commonly used as a payload in exploitation, utilizes theCamelliasymmetric block cipher.

Active-relay vs. Store-and-forward models:An attacker can actively relay traffic through an intermediate host or store data on an intermediate host for later forwarding. Active relays

prove easier to detect through previous statistical approaches. Coskun and Memom[CM07] initially described the challenge with store-and-forward relay nodes as a component of

stepping stone attacks. They identified that intermediate hosts could (1) introduce delay

constraints, or, (2) store data before forwarding. They highlighted peer-to-peer file-sharing

and email relaying as examples of store-and-forward relay nodes. Store-and-forward relay nodes can exist to purposely introduce noise (e.g. meaningless chaff packets)[Pen05]or delay to defeat statistical correlation or watermarking correlation techniques. As an example,

consider the difference between an active-relay intermediate relay node that establishes

SSH Port Forwarding versus an intermediate relay node that encrypts and compresses a

file before relaying the traffic. In the former case, it is easier to correlate the attack flows

using some kind of flow watermarking[Pen05]whereas in the latter case, any embedded flow watermark is lost which means that flows cannot be correlated anymore.

Attackers use various different models of stepping stone attacks for exfiltrating

infor-mation during a stepping stone attack. These include active-relay, store-and-forward, and

split-relay which can make the detection of such attacks challenging. In a typical stepping

stone attack[Shu11], an attacker passes traffic through a series of internal and intermediate hosts to bypass network controls that typically stop an external attacker. As seen in the

figure, a stepping stone attack may use a series of intermediate hosts to construct an attack chain. However, an attacker can evade detection by inserting chaff and delay or splitting

the attack through different sessions.

(18)

used by internal clients (e.g. a webpage). The attacker then places malicious code on the external resource to infect the internal resource and gain remote access. In this model,

the establishment of the stepping stone chain begins when the internal node establishes

a connection out of the network. This is different than naive attacks that begin when

an attacker remotely accesses an internal resource (e.g., brute-forcing SSH credentials).

An attacker could even split the packets among different exfiltration channels, sending

out a part of the sensitive data through a covert DNS channel[Ver16]while using HTTP Beaconing[Buc16]to exfiltrate the rest.

2.1.2 Stepping Stone Attack Maneuver

Attackers use several different maneuver methodologies to creatively bypass enterprise

network security. Next, we examine how an attacker may laterally pivot in 3 ways - 1) using legitimate access, 2) using an established internal foothold, or 3) stay-behind internal

forwards. Each of these different models presents a unique design challenge for PivotWall.

Pivot through legitimate access:Often attackers use stepping stone attacks (i.e., lateral pivoting) to bypass typical enterprise defenses (e.g., intrusion detection/prevention sys-tems, firewall devices) by borrowing from the trust associated with an intermediate host.

While an external attacker may lack the permissions to access a software code repository,

an internal host in the business development network has unrestricted access. Thus, an

attacker initiates a stepping stone attack by using legitimate credentials for a remote access

(e.g., VNC, SSH, Remote Desktop) to a host in the business development network and uses

this host as a pivot point for further steps of the attack.

Pivot through established internal foothold:An attacker may choose to establish a command and control server or a complex remote access toolkit (RAT) on an intermediate node. By

planting thisfoothold, the attacker establishes consistent means of attacking the internal network with a complex set of tools. An example of a commonly used foothold is the

Metasploitmeterpretertoolkit[May11]. An attacker can use an active meterpreter session to route traffic through an intermediate host, scan and enumerate internal targets, and

launch further network attacks from the vantage point of the foothold.

(19)

In some cases, an attacker may even be capable of establishing an internal forward without introducing attacker toolkits by the use of operating system mechanisms such asIPtables.

2.1.3 The Purpose of the Stepping Stone Attack

Studying and classifying the attacks based on the purpose of an attacker proves useful in

the design of PivotWall. We consider attacks on confidentiality and integrity as the goals

of an attacker. Wang et. al[Wan15]have adequately addressed utilizing SDN to identify attacks against availability of services.

Attacks against confidentiality:In these attacks, the attackers ultimate goal is to exfiltrate some sensitive data or information from inside the network to the attackers’s machine which

is external to the network. The attacker can use any of the previously mentioned attacks

mechanisms to carry out such attacks. Commonly referred to as data-loss, an attacker’s

goal is to exfiltrate sensitive data out of the network. An attacker may steal sensitive data

using a variety of channel attributes and maneuver techniques.

Attacks against integrity:In these attacks, the attackers ultimate goal is to compromise or corrupt the sensitive hosts and internal services which might further lead to corruption

and/or disruption of normal functioning of the network. Here, too, the attacker can use any of the previously mentioned attacks mechanisms to carry out such attacks. As an example,

an attacker may use a stepping stone attack to gain access to a source code repository to

change a critical file.

2.2 SDN Background: What constitutes SDN?

2.2.1 SDN architecture advantages over traditional network

SDN architecture provides quite a few novel functionalities that traditional network

archi-tectures lack. Some of them being:

• SDN enables administrators to easily and directly program the network controls as

they are decoupled from the forwarding functions. Due to this decoupling, it also

enables for swift dynamic traffic engineering and traffic-adjustment based on the

(20)

Figure 2.1 SDN architecture overview with various components

• SDN allows for central network management by SDN controllers that act as single

logical vantage point and have a global view of the whole network. The actual network

is abstracted from the applications that run the controller and the policy engines as a single logical switch.

• SDN enables dynamic configuration and management of network devices through

programmable SDN applications that run on the controller. These applications can be easily written using a set of APIs and protocols, such as OpenFlow, to control and

manage the underlying network without worrying about any proprietary software.

• SDN also enables the network security administrators to have a global perspective of the whole network and makes it easier for them to see all the active flows from a single

vantage point without the need of distributed sensor placement and also allows for

swift reactive measures to be taken against any detected malicious activity. The effects

of such mitigation steps spread across the whole network almost instantaneously.

(21)

to use any given hardware and also simplifies the network design.

2.2.2 SDN architectural components

SDN comprises of several architectural components that perform one or more of the above mentioned functionalities. The architecture can be divided into 4 different planes which

serve distinct purposes and have their own defined functions. These planes contain one or

more entities or components working independently or together to perform the tasks of a

given plane. The planes talk to each other through various interfaces via open APIs and

protocols. Figure 2.1 describes the overall architecture of SDN and mentions how these

different components present in different planes work together and talk to each other

through various interfaces.

2.2.2.1 Planes/layers identified in SDN

The different planes with their components and functions are as follows:

Data plane:The data plane is comprised of a set of one or more network elements, such as switches etc, each of which contains a set of traffic forwarding or traffic processing

resources. The forwarding rules present on the switches are stored in flow tables as

flow-entries that are set by the SDN controller. The SDN architecture document by the Open

Networking Foundation(ONF) states thats the data plane incorporates the resources that

deal directly with customer traffic, along with the necessary supporting resources to ensure

proper virtualization, connectivity, security, availability, and quality.

Controller plane:The controller plane is comprised of a set of SDN controllers that have an exclusive control over a set of resources exposed by one or more network elements in the

data plane. As stated by the ONF, the SDN controller plane is modelled as the home of one

or more SDN controllers. The major role of the SDN controller is to execute the requests

of the SDN applications it supports and keep the applications isolated from each other.

Since a network may have more than one SDN controller setup, an SDN controller may

communicate with its peer SDN controllers, subordinate SDN controllers, or non-SDN

environments, as necessary. to perform the mentioned functionality,

Application plane:The application plane is comprised of one or more applications, each of which has exclusive control of a set of resources exposed by one or more SDN controllers. Several applications can be operational at the same time performing various different tasks

(22)

controller plane. An application may invoke or collaborate with other applications and can also act as an SDN controller in its own right.

Management Plane:The management plane is comprised of management consoles for applications, SDN controller and network elements with each of the other planes having

functional interfaces to a manager. As is stated by the ONF, the major functionality of the

manager is to allocate resources from a resource pool in the lower plane to a particular

client entity in the higher plane, and to establish reachability information that permits the

lower and higher plane entities to mutually communicate.

2.2.2.2 Interfaces identified in SDN

To enable smooth communication between the planes and their underlying components,

there are several interfaces that we describe in this subsection.

Northbound interfaces (also known as the application-controller plane interface (A-CPI) ): The northbound interfaces exists between the controller plane and the application plane

and enable the communication between them. Several different applications can be

opera-tional in the application plane and can communicate with the controllers using certain

APIs exposed by controllers. The controllers also respond to applications’ requests and pass on information, events etc to the applications using this interface.

Southbound interfaces (also known as the data-controller plane interface (D-CPI) ) :The southbound interfaces exist between the controller plane and the data plane and enable

the communication between the controllers and the network devices or elements. The

communication across this interface uses an open standard protocol such as the OpenFlow

protocol. The controllers as well as the network devices should have the support for the

messaging protocol. The most common communications across this interface happen

when the controller tries to alter the behavior of the underlying network by sending control

messages or when the network devices send events up to the controller.

East-West bound interfaces (EWBI):A network may have a set of distributed controllers which need to communicate with each other to maintain synchronisation with each other,

pass data between between each other or send notifications or updates. The east-west

bound APIs exist inside the controller plane and between the different controllers to allow

them to communicate with each other.

(23)

perform management functions across the planes like setting up the network elements, assigning the SDN controlled parts, configuring the SDN controllers, monitoring the

per-formance of the system, setting up security associations etc.

The communication between the control plane and the data plane uses a SDN

messag-ing protocol with OpenFlow bemessag-ing the most widely used messagmessag-ing protocol.

2.2.3 Threat Model

Our threat model accepts that an attacker is capable of bypassing existing enterprise defense

mechanisms to gain access to an intermediate stepping stone. An attacker may compromise

the intermediate host through a server-side vulnerability, exploit a client-side application,

or simply gain access through the use of compromised credentials. Our model examines

attacks that rely on a communication channel to control the attack. We do not consider attacks where malware automatically propagates through the network without

commu-nication of any sort back to the adversary, e.g. Stuxnet. We do consider cases where an

attacker may attempt to hide communication through the use covert network channels

(e.g - HTTP Beaconing) or generate excessive traffic to mask the next hop in thestepping stoneattack. We assume protected resources can be identified ahead of time.

Our trusted computing base (TCB) consists of the SDN controller, the host agent, the

SDN application, the communication channel between the host agent and the network

controller, and the enterprise networking devices and their communication with the

con-troller. We make the following assumptions with regards to the TCB. We do not consider attacks against the SDN controller in this work. Additionally, we do not implement host

attestation as part of our prototype. We assume that host attestation could be accomplished

through existing implementations such as Open CIT[AQU16]. Finally, we do not consider the possibility of a compromise of an enterprise networking device that would either 1)

fail to forward relevant matching data, or, 2) deliver spoofed or manipulated events to the

controller. We consider the attestation of enterprise networking devices as an orthogonal

(24)

CHAPTER

3 OVERVIEW

In this section, we explain the unique challenges faced by PivotWall. We then provide

an overview of PivotWall’s approach using a motivating example. This example briefly

illustrates how we handle the challenges presented by complex stepping stone attacks.

(25)

PivotWall prevents stepping stone attacks by tainting critical resources and examining the propagation of network flows by considering the context of the host. Detecting stepping

stone attacks requires overcoming the following challenges:

C1 Attackers use a variety of techniques to evade detection.Prior methods for detecting stepping stone attacks rely predominately on either flow correlation techniques based on flow characteristics such as inter-packet delay (IPD)[ZP00; Wan02]or use active watermarking of packets[WR03; Wan05a; Wan05b]. However, an attacker can evade timing and watermarking based detection by various means such as including delay,

padding,chaff, and packet repacketization[Don02; Pen05; Pos81; Pyu12]as well as specific attacks on timing and interval based network flow watermarking[Kiy08; Luo11; Pen06]. Ultimately, detecting and correlating the flow of provenance across the network and hosts requires fine granularity that is not vulnerable to attacks that

introduce delay, padding, repacketization, or compression.

C2 Network flows are commonly encrypted, preventing the inspection of content.The in-creasing growth in the usage of encryption in standard applications prevents content

inspection by most intrusion detection systems. To address this limitation, typical

en-terprise defenses install Certificate Authorities on all clients and essentially perform

SSL interception, which is a kind of a Man-In-The-Middle attack[SS11]. However, this method results in a weakened network posture and compromises the intended

confidentiality of the encryption protocol.

C3 Stepping stone attacks can be relatively brief and require a reactive response.Often stepping stone attacks do not require a substantial period of persistence on the intermediate pivot hosts. Consider the attack against the Juniper Firewall NetScreen

software to illustrate this challenge[Zet16]. In the case of the Juniper breach, an adversary compromised the software code repository of Juniper in order to change a

single line of code that introduced a backdoor into the NetScreen software. Methods

that rely on a statistical detection of packet characteristics require a sufficient period

of monitoring packets to properly classify an attack and cannot identify and respond

within an appropriate window to prevent such attacks.

Figure 3.1 depicts an example stepping stone attack that we use to motivate our work

(26)

protected host. The protected host exists in a protected VLAN segment of the network that prevents external access. To bypass the enterprise network controls, the attacker routes

his traffic using the proxychains [Net13]toolkit through a legitimate SSH session on a intermediate node (i.e. vuln-host.)

The high level idea of PivotWall is to track the propagation of taint across the network

starting from any protected resource. It involves a per flow granularity taint tracking and

provenance logging on the network level in addition to file and process granularity taint

tracking and provenance logging on the hosts. Combining the context gathered by the

network and host is a key piece identified by our work which makes the detection of a wide

variety of stepping stones possible. We examine how PivotWall addresses the challenges by labeling protected resources as taint sources and labeling external networks as taint sinks.

By propagating the taint from the victim to the attacker, PivotWall offers finer granularity

than solutions that rely on inbound tainting.

We now detail how PivotWall detects the stepping stone attack. In Step 2, the internal

VLAN switch sends an OpenFlow packet-in event to the PivotWall SDN application

indicat-ing the new flow from the Internet to

DevHost

. This flow is allowed. In Step 4, the protected

VLAN switch sends an OpenFlow packet-in event to the PivotWall SDN application

indi-cating a new flow from

DevHost

to the

GitServer

. Again, the flow is allowed. However,

the return flow for the TCP SYN-ACK causes Steps 5A and 5B. In Step 5A, the PivotWall SDN application informs the

DevHost

host agent that the process corresponding to the

flow from the

GitServer

should be tainted. Simultaneously, in Step 5B, the PivotWall SDN

application deletes all external flows from the

DevHost

to ensure it can mediate all future

output traffic. In Step 6, the

DevHost

host agent propagates the taint to the TCP connection

used by the attacker’s SSH connection. It then informs the PivotWall SDN application that

this flow is tainted. Finally, in Step 7 the PivotWall SDN application detects the pivot when

the SSH connection attempts to send a response to the attacker.

Note that this same operation occurs for both confidentiality and integrity attacks. For

(27)

CHAPTER

4 DESIGN

4.1 PivotWall

As depicted in Figure 3.1,PivotWallhas two main components that work together to ac-complish the system goals - 1) the SDN application that monitors the network connections

to maintain and propagate network level taint information and to respond to detected

pivoting attacks and, 2) the host agent module that monitors the processes and

applica-tions running inside the host to perform data provenance and propagate host-level taint

information. The SDN application assists the host module by notifying the host when it

is tainted and the host module assists the SDN application by notifying the controller if

it detects any outgoing tainted connection from the host. The SDN application uses the network state along the network taint information to monitor the connections and detect

the presence of pivots or stepping stones in the network. The following sections discuss the

design of each component in detail and the roles and functionalities assigned to them for

(28)

4.1.1 Network Level Taint Tracking

PivotWall uses an SDN application to perform the network level taint management and

also to monitor the state of the network at any given moment. A naive way for network level

taint tracking is to use the external network as thetaint sourceand the hosts connecting to the protected resources as thetaint sink. The first step would be to taint any flow that has an external entity as one of the end points and notify the host of the external connection so

that the host agent can perform host-level taint propagation. The host and the SDN app

can then collaborate with each other to propagate taint to other hosts based on established

flows and finally track the movement of the taint to a protected resource. This is when a

flow gets flagged by the SDN app and the appropriate responses are triggered.

However, using the external network as the taint source has the the following drawbacks:

• Taint Explosion:This might cause a lot of hosts in the internal network to be tainted as most of the internal hosts maybe allowed to access the external network and download

files from the internet. So any host that performs such actions will be tainted even though only a small fraction of these hosts may actually be communicating with the

protected resources.

• Host Agent Overhead:The host agent might need to perform dynamic taint manage-ment on the host filesystem even though the host contains no sensitive data from the

protected resources or has no active connection with the protected resources. This

may also lead to overuse of resources in cases where a host downloads files from the

external network frequently but very rarely downloads anything from the protected

resource, which is of main importance.

• Attack Targets Already Identified:The naive way mentioned above does not leverage the fact that the end targets for the attacks are already known in an efficient manner.

This information can be used to come up with a more optimal solution based on a

different design which we present below.

PivotWall is aimed at detecting and stopping the stepping stone attacks where the

end goal of the adversary is either to exfiltrate information originating from the protected

resources or to compromise the integrity of the hosts identified as sensitive or protected.

(29)

Hence, it makes sense to track the connections and the flow of data from the protected resources to the outside world, i.e., in the opposite direction of the attack chain formed by

the attacker.

Essentially, PivotWall needs to keep track of the flows that - 1) have protected resources

as one of their end points, or, 2) have been be setup by a process on a host that was previously

tainted by the host agent. The latter is possible with the assistance from the host and is

discussed in the next section. By performing a taint propagation starting from the protected

resources, the SDN app is able to backtrack a stepping stone connection chain formed

inside the network and detects the attacks at the initial internal node belonging to the

chain. This backtracking starts from the protected resource being targeted and essentially traverses the chain in the reverse direction as that of the attack. The detection happens just

before the flow is about to leave the internal network.

A key component of the PivotWall design is the network taint analysis performed by an

SDN Application. The concept of taint analysis in security research is well covered for the

domains of operating systems and program analysis. In its most basic form, network taint

analysis defines a host or network (e.g., Internet) as a taint source, a host or network as a

taint sink, and a propagation logic (e.g., when tainted host A sends a packet to untainted

host B, propagate the taint to host B). When a tainted host attempts to send a packet to a

taint sink, some action (e.g., drop packet) is performed.

Taint propagation can be centralized or decentralized. For example, in an operating

system, the kernel can perform centralized taint propagation between processes and files. In

contrast, decentralized approaches rewrite programs to propagate taint between variables

or registers. Watermarking is an example of decentralized taint propagation in a network.

PivotWall builds on top of the OpenFlow SDN framework to achieve centralized taint

propagation. Essentially, the SDN application becomes a reference monitor for the network.

SDN applications gain a network holistic perspective by receiving packet events from

enterprise network devices. For example, an OpenFlow enabled switch can be configured

to send the SDN application a packet-in event for each previously unseen flow. A flow is defined as a 5-tuple: source IP address, destination IP address, source port, destination

port, and protocol (e.g., TCP). Hence, each TCP connection consists of two network flows:

one flow in each direction. In response to the packet-in event, the SDN application can

tell the switch to drop the packet, flood the packet to all ports, or forward the packet to a

(30)

the connection do not need to be sent to the SDN application.

A naive instantiation of network taint analysis will quickly devolve into taint explosion:

the state where all hosts are tainted. PivotWall addresses taint explosion in two ways. First,

it supplements the network-level taint analysis with host-level taint analysis. The PivotWall

host agent performs taint propagation on the granularity of processes and files. Although

this is a coarse grained taint propagation and can lead to less accurate results than a more

fine grained approach, it incurs significantly less performance overload on the system

than the latter. Second, PivotWall uses protected (sensitive) hosts as taint sources. From

a traditional perspective, the Internet would be the taint source. However, our intuition

is that hosts communicate with the Internet significantly more than protected hosts. As a result, there will be less tainted flows, which leads to less tainted host processes and files,

which leads to less taint explosion due to imprecise tracking. The reduced number of taints

also decreases the size of the graphs created during forensics investigation.

Using the protected host as the taint source is effective for both confidentiality and

integrity attacks. For confidentiality attacks, tainting starting at the protected host acts as a

form of data loss prevention (DLP). For integrity attacks, tainting starting at the protected

host is effective, as long as the integrity attack involves an active command and control

channel and a TCP connection. The reason is that the TCP handshake will propagate the

taint back to the initiator during the SYN-ACK, and therefore detect the pivot before the malicious command can be sent. In the case of multiple relay nodes, the taint will follow

the flow back to the Internet as part of the interactive session needed by the command and

control channel.

The taint propagation being performed by PivotWall host agent is not fine-grained. The

host agent propagates taint on a file and process level but it is possible to perform a further

fine-grained whole-system provenance tracking by monitoring on actual bit level. Although

this would help increase the precision of the host agent, it can lead to significantly higher

performance overhead as it is a very costly operation. Even state of the art whole-system

taint analysis tools[Hen16]can lead to a 600% performance overhead. Doing this would make PivotWall practically impossible to deploy on real world production systems. Keeping

this is mind, we decided to let the host agent perform a comparatively coarser grained

taint-propagation on file and process level, which is commonly used to enforce information

(31)

present on the hosts will already be performing some level of taint analysis and notifying the SDN controller of any flow that might be transmitting tainted data. So from the network

perspective, there is no need to perform a finer-grained taint analysis than what PivotWall

currently does, which is at flow level. Performing a finer-grained analysis on network level

would not necessarily result in better precision but will certainly increase the performance

overhead of the system.

There are five main aspects for network taint management and monitoring as discussed

below:

4.1.1.1 Categorization of the network into different subnets

Enterprise network topologies typically consist of different categories of hosts based on

their sensitivity, functionality, users accessing the hosts, etc. These categorizations can

be easily maintained using different subnets for different categories. PivotWall can be

configured with this information using a configuration file that the SDN module reads to

identify different set of hosts. It also learns, from this file, the default counter actions to

execute in case one or more hosts belonging to the categories are detected as pivots. Of

primary interest to PivotWall are the hosts marked sensitive and are referred to as protected resources. These resources, typically, have no interaction with the external network and

only internal hosts are allowed to talk to them. There are other hosts that are less sensitive

and are allowed to communicate with the external network and/or download data from the internet as well.

4.1.1.2 Protected Resources as Taint Source

The SDN app needs to identify flows originating from a protected resource in order to

perform tainting and logging provenance data. Therefore, while bootstrapping, no flow

entries are added to the flow tables of switches which have a protected resource as an end

point. In an SDN setup, the switches are configured to send a packet from any unseen flow

to the controller. This guarantees that whenever a host tries to establish a connection with the protected resources for the first time, the packet is sent up to the controller. The SDN

app, on receiving such a packet, first checks if the recipient host has the agent running on it

or not. This information is available to the app via the configuration file discussed earlier. If

(32)

PR1

H1

H2

Network Taint DB

TN1: to H1{flow f1from PR1to H1} f1

TN2: to app {Outbound tainted f2}

PivotWall SDN Application Get/Set Taint Data

OpenFlow

Control Messages f2

Switch1 Switchn

Protected Resources

Normal Hosts Network Devices

p1

p2

PRn

*TN – Taint Notification

Figure 4.1 Network Monitoring and Taint Propagation

netcat. The host agent is already configured to listen for such communication on a specified

TCP port and this mapping is stored in the configuration file which is accessible by the app.

The app notifies the agent to mark the port on which it is about to receive packets from the

protected resource as tainted. This taint notification is read and acknowledged by the host

agent running on the host. After the SDN app receives the acknowledgment for the taint

notification, it then adds a flow entry to the flow table on the switch. If the host does not

have a host agent running, the app does not send a taint notification, but instead, just adds

the host to the database of tainted hosts so that any future outgoing connections from such hosts can be flagged for taint propagation to other hosts.

4.1.1.3 Taint Propagation

The host agent performs host-level taint management (discussed in section 4.1.2 ) on an

already tainted host and sends a notification to the SDN app via a TCP connection if it

detects a need for the taint to be propagated to other hosts. This happens when an already

tainted host tries to communicate with another host. The taint message contains the IP

address of the recipient host along with the port to be tainted and also the originating

port number of the sender. The SDN app, on receiving such a taint message from a host,

acknowledges the message and performs a check to see if the recipient host belongs to

(33)

tainted and sends a taint notification to the host informing the agent of the port that has to be tainted. It inserts a flow rule on the respective switch to allow the communication

between hosts and performs similar operations as we discussed in section 4.1.1.2.

In cases where the recipient host does not have an agent running, the taint notification

is not sent and the host is added to the database of tainted hosts as discussed in section

4.1.1.2. Since these hosts have no way of informing the app of any tainted connections

leaving the host, the app needs to monitor all outbound connections from such tainted

hosts and propagate the taint to other hosts communicating with them. Thus the SDN app

uses its flow monitoring capabilities along with local taint database and configuration file

in conjunction with the host agents running on various hosts to propagate taint across the network.

In Figure 4.1, when a Protected resource (P R1) establishes a connection withH1using

flow f1, the switch sends the first packet to the controller, from where the app reads it and

checks if an agent is running onH1. If yes, it notifiesH1of the taint via a TCP connection

(T N1) and waits for the acknowledgement before setting up a flow table entry on the switch.

It marksH1, that is about to receive an inbound flow from a protected resource as tainted

and stores the host address and the port number in the taint database. IfH1does not run

the host agent, the notification is not sent but it is still added to the database of tainted

hosts. The host agent present onH1does host level taint tracking (across processesp1, p2)

and when it sees a tainted flow (f2) about to leave the host, it sends a taint notification (T N2)

to the controller with the information about the flow. The SDN app, in turn, propagates the

taint toH2via a taint notification (T N3). The entries corresponding to the hosts that do not

have an agent running on them is never deleted from the DB until the hosts are manually

restored to an untainted state. The SDN app uses the northbound APIs of the controller

to send down OpenFlow messages to all the switches (1 through n) instructing them to

remove the flow entries that originate from such a host. The entries for the remaining hosts

that have a host agent running are deleted once the corresponding flow entry is deleted

(34)

4.1.1.4 Pivot Detection

The SDN app also performs the check to detect the existence of pivots or stepping stones

in the network. When an already tainted host sends a taint notification to the SDN app, it

learns that the host agent has detected a tainted connection leaving the host (see section

4.1.2). The app then checks if the tainted connection is leaving the internal network or not. To accomplish this task, whenever the SDN app receives a taint notification, it first

performs a check to determine if the destination IP address belongs to the internal network.

This information is available to SDN app via the configuration file (discussed in section

4.1.1.2). If the destination IP belongs to the internal network, the SDN app continues with

the taint propagation steps mentioned in section 4.1.1.3. In case the destination IP does

not belong to the internal network, the app flags the flow and marks the sender host as a

pivot or a stepping stone.

In addition, when the app sees a connection going out to the internet, it checks if the

originating host has an agent running on it. If the host does have an agent running, the app allows the connection to be established because if this were a tainted connection, the agent

would have already notified the app about it. If the host does not have an agent running,

the app then checks if the host is already present in the tainted-hosts database and flags

the connection if it does. After the SDN app flags some hosts as being a potential pivots or

stepping stones, it then proceeds to take certain counter measures which we have discussed

in sections 4.1.1.5 and 4.1.3.

4.1.1.5 Counter Measures

After the SDN app detects the existence of a pivot or a stepping stone in the network, it

uses the capabilities provided by SDN architecture to take one or more counter measures

possible and communicate this to the controller using the northbound APIs, which in turn further updates the data plane in compliance with these policies using the OpenFlow

protocol. Since the controller is the single logical control point for the entire network, these

counter measures are propagated throughout the network efficiently and the network

wide effects can be seen almost instantly. There is no manual effort required to change

the configuration of the network devices as the SDN app is already programmed with the

counter measures that are automatically triggered whenever a pivot is detected. We have

(35)

nc -lvp 1337 > foo ; gzip -c foo > bar ; scp -r bar user@ftpserver:/var/ftp/pub TCP 1337 NC FOO GZIP BAR SCP TCP 21 SDN Controller Informs Host

To Taint TCP:1337 w/ connectionTaints PID PID TaintsOpen File File TaintsPID PID TaintsOpen File File Taints

PID PID TaintsNetwork

SDN Controller

Informs SDN TCP:21 is Tainted

Figure 4.2 Host Agent Monitoring and Taint Propagation

access to the configuration file which can be used to configure the app to apply different

measures to different sets of hosts based on their sensitivity, functionality, etc.

4.1.2 Host Based Data Provenance

In this section, we explain the design of the agent1_{that propagates provenance across the}

host. A key assumption of PivotWall is that hosts are capable of monitoring provenance

propagation and sharing their context with the SDN controller. We illustrate the basic

scheme and responsibility of our host agent in Figure 4.2.

In this example, an attacker receives tainted data over a netcat listener, compresses that

data into a new file, and the securely copies the file to a remote ftp server. The example

illustrates the causality between taint notification, network handle, processes, and file

access. As demonstrated by the example, the host agent must maintain the correlation and dependency between these system objects. Our prototype agent stores these correlations in

a SQLite database on the host. In our prototype agent, we utilize the following application

programming interfaces to the Linux kernel.

The host agent monitors the network communication with the help of libnetfilter_-queue[Wel00]APIs. The agent has the task of informing the SDN app whenever it observes any tainted data being sent out over the network. The agent also monitors the process and

system data from theprocdirectory in order to gather intelligence about the movement of tainted data inside the host and maintains this information is a database. In order to

properly propagate taint across files and processes, the agent also intercepts filesystem events in realtime usingfanotify[Cor09](Linux Filesystem Access Monitoring) APIs.

To achieve good performance, our host agent maintains limited metadata about the

network handles, process information and file access events. Our results in Section 6.3

(36)

Kernel

SDN Application

Processes Files Network Handles SDN Message Agent

Network Monitoring (netfilter)

File Monitoring (fatrace)

Process Listener (pid tables)

Host Agent

Taint Database

send/receive info about tainted flows monitor files, network handles, processes

store/query taint data about objects kernel / userland boundary

host / network boundary

Figure 4.3 Design of Host Agent

indicate that monitoring realtime filesystem events incurs the largest but tolerable affect to

overall system performance.

Handling Imprecise Taint Propagation:As discussed in Section 3, we chose process-level taint propagation as a trade-off between performance and tracking-precision. A problem

with this approach is that it might lead to a false propagation of taint by the PivotWall host

agent in cases where the same application is used to process both tainted and untainted

data. Our experiments in Section 6 identified two cases where this false tainting becomes

problematic. The first case followed directly from this expectation: when gedit is has two

open documents (one sensitive, one not), the taint is propagated to the non-sensitive file.

The other case occurred when an application saves state in a file and reuses the state for

subsequent executions. For example, we observed such taint propagation with Firefox due to to a cache file and Google Chrome due to the history recording.

These false taint propagations can be mitigated in practice at the expense of security or

usability. For example, false taint propagations can be mitigated by whitelisting specific

applications. There is increased security risk when whitelisting applications, as the attacker

could abuse the whitelist to exfiltrate information. However, if a whitelisted application is

uncommonly used in attacker tradecraft, there is still significant benefit of deploying the

system.

A second method of mitigating the false taint propagations is to have users chose

differ-ent applications for differdiffer-ent tasks. For example, a user could use Firefox when accessing

company Web servers and Google Chrome when browsing the Internet. This method has obvious usability drawbacks, but may be reasonable in more sensitive environments. Since

(37)

appli-cations or files that deny access instead of propagating taint. This concept is known as setting a label ceiling (proposed in IX[mcil1992multi]) and was recently used by Simple-Flow[john2016simple]for mitigating insider attacks. Our experiments in Section 6 assume the separation of applications. We plan to investigate the incorporation of SimpleFlow into

PivotWall in future work.

Tamperproofness:As discussed in our threat model, our PivotWall implementation assumes the host kernel and privileged applications are free of vulnerabilities. We implemented the

PivotWall host agent as a userspace process primarily for convenience, as our goal was to

create a proof-of-concept prototype rather than a production ready solution. We plan to

explore the integration of prior approaches including SimpleFlow[john2016simple]and Linux Provenance Modules (LPM)[Bat15]. Note that the agent does not necessarily need to execute within the host. A host agent based on LibVMI[Xio12]running within a hypervisor is also possible. Moving the host agent into the hypervisor would further reduce the trusted

computing base.

4.1.3 Response to detection

Managing the defense of stepping stone attacks at an SDN controller introduces several

unique and different response methods. Since the controller manages the data plane of

the network, the controller has the capability to communicate with all enterprise network

devices in response to an attack. By sending control messages across the data plane, the

SDN controller can near instantaneously communicate and propagate knowledge of a threat to all managed enterprise network devices. In the following section we discuss some

of the possible actions that PivotWall can be configured with once an attack has been

detected. The actions mentioned here are not exhaustive and can vary depending on how

conservative security administrators want to be in response to detection.

• Isolate Suspected Hosts: The controller application can be configured to fully isolate

the suspected host from the network by simply sending a control message to all

switches. All the flow table entries that have the suspected host as source or

desti-nation are deleted from the flow tables of all switches and for the time the host is present in suspected table in the database, controller does not add another flow entry

on the switches for that host. This, essentially cuts off all communication to and fro

(38)

• Restrict Outbound Traffic: The controller can also manipulate the flow entries on the switches to restrict most of the outbound traffic from suspected hosts. It can

put restrictions on the upload limit of the suspected hosts until they are sanitized, if

the security administrators believe that the hosts could be exflitrating large sets of

internal data. This will not have huge affect on the hosts? functionality and the users

can still perform normal operations on their computers.

• Redirect to Honeynet: Some networks have specially crafted honeynet for running

real-time forensics on active attacks on the network. This helps understanding the

attacks and the vulnerabilities targeted by them. It also helps to create signatures for unseen attacks and study the evolution of attacks. Once an attack is detected, The

controller application can immediately direct all traffic bound to the suspected hosts

to the honeynet which increases the chances of performing real-time forensics on

the attacks.

• Automated Rule Generation for Internal/External Firewall: Since PivotWall maintains the current state of network along with the information on tainted hosts and the

hosts suspected of being pivots, this can be used as an input to an automated system

for dynamically generating policies and rules for the internal and external network

firewalls. This can specially benefit by helping create dynamic rules which may have been missed during static generation of firewall rules.

• Traffic Throttling: Throttling refers to actively limiting the host’s upload and/or down-load speeds over the network. The controller can be configured to perform traffic

throttling on the suspected hosts, thus limiting their communications while

keep-ing all other functionality intact. This gives more time to security administrators to

observe the hosts behavior and be confident of an active attack before taking more

drastic steps, like isolating the host.

• Assist IDS SDN Application: The controller can delete all flow table entries on the switches that have the suspected hosts as an end point and thus, force the switches to

send all the packets up to itself. The controller can then pass these packets to an IDS

application running on it that can perform packet inspection. This way, PivotWall

(39)

4.1.4 Provenance Graph Discovery

This section examines how PivotWall discovers the graph of actions that lead to a taint

propagation egressing the network. Since PivotWall taints on the egress traffic, the SDN

application must reversely iterate through each stepping stone until it reaches the original

taint source of the protected host. Because individual objects (e.g. a tainted file) can be

tainted by multiple tainted processes, a host may need to recursively discover the multiple

taint sources that originated the taint. Algorithm 12_{depicts the provenance discovery by}

both the SDN application and host agent.

Algorithm 1:Provenance_Discovery(flow)

S_←Set of tainted objects (both host and network); flow_←flow from stepping stone to external net ; whileWhile flow.src∈/protected resourcesdo

H_←Set of collaterally tainted objects from flow.src ;

forflow in H.rootsdo

S_←S_∪Provenance_Discovery(flow.src) end

end return S

Both the network and the host maintain provenance data about taints in sqlite databases. Thus, both the host agent and SDN application simply query the sqlite databases to return

the set of collaterally tainted objects depicted in Algorithm 1. Producing this set and

aggre-gating the data over the network allows an incident response team and forensic analysts

the ability to contain the threat of the attack and eradicate their presence on the internal

network. Figure 4.4 depicts the type of data constructed through the provenance

discov-ery algorithm. The SDN application gains visibility of the taint source, the intermediate

hosts involved and the series of intermediate tainted objects (processes, files, and network

connections).

(40)

Fname Taint PID File Perms Timestamp

/home/user/secrets 7335 R 477706666 Flow.Src Flow.Dst Flow.Sport Flow.Dport

10.4.4.3 (internal) 10.5.5.1 (external) 3194 8080

Process ID

7335

Timestamp

477706777

/etc/init.d/rootkit 7335 W 47770655

/etc/shadow 7335 W 47770643

/etc/passwd 7335 W 47770632 Inode

2638936 45890

45770 2638934

Flow.Src Flow.Dst Flow.Sport Flow.Dport

10.4.4.4 (protectedl) 10.4.4.3 (internal) 3195 1337

Process ID

7335

Timestamp

47770544

Fname Taint PID File Perms Timestamp

/home/user/secrets 6945 W 47770621 Inode

2638934

Host Agent Provenance Discovery Flow.Src Flow.Dst Flow.Sport Flow.Dport

10.4.4.3 (internal) 10.5.5.1 (external) 3194 8080

Flow.Src Flow.Dst Flow.Sport Flow.Dport

10.4.4.4 (protected) 10.4.4.3 (internall) 3195 1337

SDN Application Provenance Discovery

Taint Sink

Taint Source

(41)

CHAPTER

5 PIVOTWALL SDN APP

As discussed in Chapter 4, as SDN app registered with the controller is used for a network

wide taint propagation that is assisted by a host based provenance module in detecting

and stopping stepping stone attacks. We use POX SDN controller which is a python based controller. The network taint propagation SDN app is written in python and follows the

design described in detail in Chapter 4. As soon as the app is starts execution in an SDN

network, it first registers handlers for various events with the controller. The app registers

the handlers for the following events:

• Connection_up This event is fired by the POX controller whenever a new switch

registers with the controller. Listening to this event makes the app aware of the all

switches present and active currently in the network and it also allows the app to

update the topology information.

• Packet_in This event is fired by the POX controller whenever any of the switches

send a packet_in message to the controller. This happens when a switch receives

(42)

Figure 5.1 SDN App Internals

switch’s flow table. The switch sends the packet_in message with the packet header

information using OpenFlow protocol and keeps the corresponding packet in a buffer.

The controller, on receiving such a message, fires the Packet_in event with arguments

being the packet header information, which switch sent the message as well as which

port on the switch was the packet received on. The taint management app listens to

this event as it enables the app to perform all of the processing to figure out if a new

flow that is being set up has to marked as tainted or are any flows leaving the network

that belong to an attack.

• Flow_stats_received This event is fired by the POX controller in whenever any of the switches sends the statistics about all the flows currently installed on the switch.

This can happen either in response for a flow statistics request from any of the app

registered with the controller or because of a configuration that states the switch to

send this information periodically. Any app can listen to this event, and can get the

information related to all the flows on a particular or all the switches. The SDN app

listens to this event as it needs to learn about the current flows installed on a switch

at times and requests for the same from the switches.

• Flow_removed This event is fired by the POX controller in response to a Flow_removed message from any of the switches. The switches can be configured in a way that

PivotWall: Combining SDN and Host Context to Defend Against Stepping Stone Attacks.

ABSTRACT

DEDICATION

BIOGRAPHY

ACKNOWLEDGEMENTS

TABLE OF CONTENTS

LIST OF TABLES

LIST OF FIGURES

CHAPTER

1

INTRODUCTION

1.1

Contributions to This Project

CHAPTER

2

BACKGROUND

2.1

Stepping Stone Attacks

2.1.1

Stepping Stone Channel Attributes

2.1.2

Stepping Stone Attack Maneuver

2.1.3

The Purpose of the Stepping Stone Attack

2.2

SDN Background: What constitutes SDN?

2.2.1

SDN architecture advantages over traditional network

2.2.2

SDN architectural components

2.2.3

Threat Model

CHAPTER

3

OVERVIEW

DevHost

DevHost

GitServer

DevHost

GitServer

DevHost

DevHost

CHAPTER

4

DESIGN

4.1

PivotWall

4.1.1

Network Level Taint Tracking

4.1.2

Host Based Data Provenance

4.1.3

Response to detection

4.1.4

Provenance Graph Discovery

CHAPTER

5

PIVOTWALL SDN APP