>>Welcome! Um, I asked for a, uh a, I asked for a for a two hour block and I got a 45 minute block and now I have like a 35 minute block so, uh, let’s go. I’m Jon Medina. Um, I’ve uh I’ve been breaking things, hacking things since I was 12. Many apologies to the uh, the Hemet Public Library in Southern California, their uh their poor networks took a beating from young uh young me. Um and so it’s especially special for me to a be speaking up here speaking to you all because you all growing up you all were rock stars to me like this is this is this is a the pinnacle of of where I wanted to be and never thought I would be so thank you very much for having me, I appreciate it. [Applause] I’m I I love this stuff I’m currently a a consulting network security architect is kinda of the box that I would put myself in. Um I uh work for an awesome company called Protiviti and I get to go around uh the country uh to various companies and break them um make them you know worry about themselves a little bit and then uh and then go in and help them and and help fix some of the problems that we find and some of the issues that we see there uh I absolutely love what I do. Um little bit about what we’re talking about today and why why I think this talk is important. So software defined networking is is no longer a brand new technology. I’m not coming here to tell you about this blu- new bleeding edge technology that is just being discovered um as some of you have seen, software defined networking has been around a while. Um, it’s now, it’s now in in use in many large companies however there’s very little presence of software defined networking talks and security related software defined networking talks specifically uh among these communities I am the second person ever to talk on software defined networking at Def Con um and last year another a team of researchers were some of the first ones to talk about it at Black Hat. Um, SDN has been around for years. And why, why is this not getting more visibility and so we’re not going to, I’m not going to assume any knowledge here so we’re gonna go through the start at the beginning and uh and show you exactly what what a software defined network looks like um, I’m breaking all rules of tech talks and not doing only one live demo but two live demos so, uh we’re not off to a good start here but we’ll- we’ll see how it goes. Moving on. Um, why Software Defined Networks? Why do we, why do we care, why do we need them, well as many of you know, networks have been around a very long time, and not much has changed, uh in a very long time. The uh TCP IP Stack, you can go buy those awesome two volume books that many of you are probably familiar with um on the TCP IP Stack, read those today they were written how many ever years ago and they are still just as relevant today. Because not much has changed. However the the architecture that we’re using over the top of these networks has changed drastically with cloud migrations and uh and new types of networking, virtualization, lots has changed and networks in many cases have not kept up. Uh from a security perspective, for why can Alice and Bob for example working on the the same floor of a company’s computers talk to each other? There’s no reason for that. At no point should two people in in two separate cubicles computers really need to ever talk to each other. They have their certain resources they go to, and they should be limited to those. However, networks are designed to make things communicate. And so that’s just what they do, and they do it well um, so in that way they, they work too well. Things are talking that shouldn’t be. Um and along the same lines, firewall rule lists are starting to get out of control. Um, in addition, they don’t they don’t work well enough. Pervising network uh resources is expensive, time consuming and it’s very difficult how do you know when you are deploying a re- uh a new a new system a ne- a new server how much bandwidth to allot that? You're stuck with a fixed amount of bandwidth giving that to that particular system un infrastructure deployment, is very expensive for those of you working on the infrastructure side, I don’t know how many of you of- have deployed a nexus switch lately, um they get a little pricey so its pricing are going up, devices are getting more complicated, and uh and and how does this all translate as we move to the cloud? Well I’m hopefully gonna demonstrate a little bit of the cloud side here as my demos are all are all place um in the cloud. So. Little bit about software defined networking, so the core, the core behind software defined networking, the logic there is moving the control plane outside and the data plane outside of the devices. So our network devices now become a lot dumber. And the logic the the brains behind it is now the software defined networking controller. Uh that’s sits sits at the top of the network so the controller’s whats makes the decisions, for the switches, and if the the switches don’t know how to handle something they ask the controller. And we’ll go into more detail on that a little bit later Um well, I do want to make clear this is not network functions virtualization. So even in AWS you can see, you can see you can download an AMI for brocade switch, uh brocade routers, juniper firewalls, that is network functions virtualization, that’s actually taking the the network hardware and virtualizing it. That's not what this is, this is a completely different and those can integrate with software defined networking, but software defined networking is is dramatically different from that and I”ll show you a what I mean by that here in just a moment. How many folks in the audience have interacted with software defined networking or know that it is in place in your companies? Look look around, there’s a there’s a solid amount of hands up right now so I’m really glad you are all here and uh and I look forward to interacting with you after the talk or during the questions here. So, just to a quick overview of what software defined networking is and how it works. First of all, what- what’s out there? So there are uh closed sourced and open sources versions, um of course Cisco has the uh has the closed source one. Um and I say that as a as a Cisco network engineer in my past uh I I I enjoy Cisco soft but Cisco and VMware have done their own sort of closed source proprietary versions of it. They work- they work quite well. The open sourced companies have uh have used open source openflow controllers that use um all open source protocols and uh and their API’s allow you to integrate things with um, um like I said before not a new technology. Uh go onto LInkedIn and do a search for software defined networking and you’ll see how many companies are using it. Um it’s a it’s a lot….. Google, Amazon, Facebook, NSA uh and most telco’s most of the 5G systems that are getting rolled out are being rolled out uh within a software defined networking architecture. Closed source or open source all software defined SDN architecture is going to look very very similar to this. So it’s divided into three real uh segments. The top segment is the application layer and that’s where your uh your business applications can interact with the SDN controller to provision network resources or monitor network traffic in any way they want. And that’s done through API calls to the uh to the control layer which actually holds the SDN controller And I’ll demonstrate the capabilities of that here with the tool that uh that I worked with some folks on on creating for this purpose After the control layer is the infrastructure layer. The that in between there is the openflow protocol where the, openflow controller or this SDN controller communicates with the switches. What’s cool about this is when deployed in a uh- in a sec- in a recommended scenario, the control channel between the controller and the switches is actually on a completely separate um is physically separated from the data channel with where the switches actually go here posts um at the bottom And so it's it's with that kind of setup it's it's almost impossible without manipulating the firmware of the switches to jump into the control channel. And unfortunately because I uh I’m short on time today, I’m not able to go into a whole lot of the red teaming side of things um with with the uh SDN controller but there’s some really cool really cool things about uh compromising SDN controllers and taking over control channels. I spoke a little bit on that at uh at Shmoocon last year So core concepts. First of all I apologize for the graphic, uh this slide was really bare without it and so I just Google image searched and that was the first thing that came up when I typed in flow and I was drunk and it ended up in there so [laughter] Core concepts of SDN. The controller sends flows which look a lot like ACL’s to switches. Uh the switches then make decisions based on those flows and forward traffic to its various destination based on that. And we’ll talk more on flows in just a second. Um, if a switch doesn’t have a flow that matches a certain type of packet it asks the controller and then the controller can either tell it, “hey, drop it” or, “here’s the new instructions start sending those flows this way” or it can send any number of instructions to the switch on how to treat that flow. And once again, we’ll, we’ll talk about more about that in a sec. Or you can finally just have a drop so it’s almost like a- like a firewall rule set so at the very bottom is your dropset and if if nothing matches any of the flows already in the switches, just kill it, it doesn’t belong there. This is what a flow looks like. Inside inside a switch. So, uh first is the rule which is the match information. And that tells the switch what to look for in the packet. Now natively it supports pretty much layer one through layer four, so any it can match anything within the packet all the way from what port it came into on the switch to the mac address to the uh to the VLAN, to the IP address, anyway all the way up to port and protocol. Once you start integrating uh different programs, different business programs as we discussed through the APIs it can now look all the way through layer 7 and you can actually find program data within the packets and match that within side inside an SDN controller So that first blue section there, I think that’s blue, I’m color blind uh is the- is the match area. The next part is the actions so what action does that is that switch gonna perform on that packet once it it matches that criteria? Lots of lots of possible opportunities and many of them will cause your ears to perk up a little bit as we’ll demonstrate later um one is it can forward packets to ports its says, “Hey if I see things inside port forward it to that port” or “if I see it coming in from this IP address, forward it to that IP address.” You can make it have very traditional switching um behaviour if you wish. Some other cool things though is you can overwrite data inside the packet. So, you can have your hosts believing they’re on one sub net when in reality, as soon as their traffic hits the switch all their sub net all their IP address information is rewritten and sent someplace else. So you can now spoof hosts anywhere in the network. You can move hosts wherever you want in the network and uh and you can do this to either secure or or actually attack a network as we’ll show here shortly. Um, and many of the things so the normal processing pipeline is is “hey switch Behave like a switch” uh “just do do your switching thing. If something weird comes up, send it to the controller”, and then uh and then obviously dropping packets are uh are another option there So let- I’m gonna fire up uh an SDN here and we can actually we can actually look at it. Let me get set up here [mic noise] [speaker exhales] All right. The VPN disconnected so I just need a minute for that to stand up. There we go [mouse clicks] So, here is the openflow controller I chose to use the floodlight controller today, um as I said before, there are there are many other vendors. This one is uh- is an open sourced product of the big switch, um, company. It’s uh it’s very stable it’s a newson production and uh big switch has all kinds of cool things you can add into it if you so choose. Uh let me just give you a short walk through of this. So um, here on the dashboard you have a- you can have multiple controllers so you can actually have kind of a split brain type logic for your network. If you choose where- where trollers- controllers can communicate to each other about different portions of your network, and uh that can provide some very high level type of segmentation as well high availability. Um, at ah- this will show you switches hosts as soon as we set it up. But a couple of other things that I want to point out that we are not going to uh get into today is uh, you can perform um, firewalling at the controller level. So, before the controller even performs logic, um, internally on the uh on the switches you can immediately define “Hey controller. These two things should never be allowed to talk” or “this network should never be allowed to talk to this network”. Um, and that’s possessed prior to uh prior to any other logic done in the controller. Um, and it can be done in a more of a-, more of a proactive way so you can actually be sending dynamic firewall rules to the controller as it sees uh, as it sees malicious traffic. Um, let me stand up our our Mininet here. So , Mininet is a great program um, how many of you have heard of Mininet or worked with Mininet? Okay, handful of you, I I highly recommend it to everyone. Even if not for SDN, it’s a great tool. So, um, [exhales] I don’t want to type all this out so I’m just gonna copy and paste it here. Oops. So what Mininet does is it simulates a network of of switches of any real type you want. And, uh and in this case it can also simulate uh SDN switches. So what I’ve done here, um, is created actually let me… let me do a little cooler network this one’s not very fun. [Exhales] [Hums] Let’s see, yeah, let’s do this one. So, you can build uh custom topologies. They’re, they’re really their possibilities are endless. And it stands up hosts underneath those switches. So, once you stand up your, once you stand up your switches it will also connect hosts to them and uh and you can interact with those hosts in any way you choose as you’ll see here. So, this is gonna take a minute for it to discover everything. So as you can see now, um we have 9 switches connected to the SDN and 131 hosts. All of which are run as uh mini bash instances on your on your host Mininet machines. So you can go in on them, you can end map from them, you can run anything you can access from BASH you can do on those- on those hosts, which is super cool. So this is the network we just stood up. So there we are. Um, and right now as you can see, oooo, squid. Uh as you can see, there are uh there’s a core switch with um basically what the topology I like to use kind of simulates more of a data center environment, so this- you can see it as almost a- as a core switch and then each one of the other switches around there are top of the rack switches with with hosts below them is how I like to visualize it and we’ll go into that a little bit later when I show you some of the security functions of this. But uh once the SDN controller so let me show you a few of the flows inside the switches here. So right now the switches don’t know much about their life so let’s go into switch number 2 here. So here’s the flow table it has one single lonely flow in there and that means output to controller. Uh so the switch has no instructions right now, it doesn’t know what it’s doing, all it knows is, “Hey if I see a packet, immediately send it to the controller ‘cause I have no idea what I’m doing.” These 234 packets are LLD- DP packets which is a- a core functionality of um of S- of openflow which has some security implications in and of itself as you can imagine but that’s what the controller uses, the controller sends LLDP p- LLDP broadcasts and that’s how it actually knows that these hosts are connected and that these switches are connected, it’s through LLDP. But as you know, it doesn’t know any of the IP addresses of these yet because uh it’s it’s only used LLDP to discover them so let’s let’s go let’s teach these switches some things. So I’m just gonna do ping all and so it has every host ping every other host and as that’s going let’s go back to our switches and we can now see that it’s learning. It’s now- the controller’s now sending flows to these switches and telling it where to redirect these packets, so you can see this packet um it- they’re given their priority um if we- if we go into the API you can actually see what the match conditions were um this particular one is only matching on uh on ethernet mac address so matching and instructions so “Hey if you see packets from here, send it out there, send it out there” and as you can see there’s multiple pages uh 586 entries at the moment and that’s just one switch so that’s the uh that’s one of the leaf switches um the core switch will probably have some fewer ones because it’s- it’s just managing all four- or five of those switches. So as you can see, that’s what the flow table looks like um and within the uh within the uh floodlight controller you can actually add static flows and so here’s what we talked about, which switch do you wanna put it on, ne- give it a unique name uh you can give it priority. So one of the other really neat things about uh about the the flow tables is you can create flow tables within flow tables like this flow table inception thing and uh and that allows you to actually have logic behind these flows. So for example you can say “Hey, I uh, I want this to be my user group, and I want all their traffic to be treated the same. I know all my users go to our three databases, they go to the internet, and they go to, y’know this file share somewhere” and you can have those- that that logic programmed in as a single flow and so when the it goes through the switches, it identifies a secondary flow table and says, “Oh this is a user- this this IP address or this host is part of the user group. Let me toss them over to this flow table and use that logic um in there” So you can actually nest and create almost uh like if then statements within the flow tables. Uh you can sa- have active- you can change the rules whether they’re active or- or not. Um so you can turn them on and off. You can also have rules that are set to timeout, which is awesome for example if you’re doing large scale patching or data migration operations, you can have flows that will redirect traffic at night over- over different channels. So one of the cool things about SDN is uh loops. You’re allowed to have loops in an SDN. Many of you network folks know that loops are uh- a horrible nightmare that Spanning Tree thankfully came along and saved us from most of the time and uh with SDN, SDN does not care. You can- you can have multiple uh links going to the same switch and it will load balance across them if you so choose, uh it won’t loop across them or you can have dedicated physical links for specific types of traffic so the the possibilities are really endless. Connect all your switches in a full mesh, nobody cares. Um very cool ‘cause you don’t need Spanning Tree. Uh so once again these- these timeouts you can uh you can timeout the flows and have traffic redirected at certain times of day or direct based on load. So you can now load balance traffic dynamically because the SDN controller knows how much traffic is going across um that’s that 3rd part that I’m getting into here. So that 3rd aspect here is the stats. That stats tracks the bandwidth, packet in, byte counters, how many times that flow was hit, all those sorts of things, and sends all that information to the controller which then aggregates it and can show your high bandwidth links, all of the uh any security issues, that sort of thing can be tracked through there. Um and that’s how you can dynamically load balance your traffic around your uh around your switches. so let me go back here, close this out. Any questions about this- this first part first before I close things down here? Yes sir! >> [inaudible off-mic audience question] >>Excellent question, so with any pure SDN network uh oh I’m so- goo- good call, so the question was, where does routing fit in, um how do- how do you do routing, he mentioned routing protocols, EIGRP uh BPB, that sort of thing. Within an SDN uh a pure SDN, IP addressing as we know it today is obsolete. You don’t need it really at all um it’s a reference that helps us in many ways to identify switches because it’s what we’re used to, but you actually don’t need it. However, where you do need it is when you’re interacting with other networks and so the controller has plug ins for routing protocols and has I- IP or BGP logic has EIGRP logic and actually uh the floodlight controller has plug ins that- that do that and you just have to enable them and it does it natively and so as soon as a BGP packet comes in um the controller can actually handle it, respond, and keep a BGP connection alive for example uh through an SDN and so the the destination network or your service provider, doesn’t know anything about it. Um within cloud uh environments it’s very very similar so for example uh many folks here uh probably work on openstack, that sort of thing uh f- openflow works natively with openstack um with plug ins and can actually manage your traffic much like the VMWare NSX does on the back end and manage your traffic for all- whatever you stand up in openstack so that’s- that’s a really cool function of it and it- it all works natively in the cloud and in many cases uh you’re actually using SDN when you’re- when you have your VPCs running in AWS and you- you may or may not know it. Um any other questions before I move out of the demo here? Yes sir >>[inaudible off-mic audience member question] >>Yes! [inaudible] So yes, the uh, I wasn’t intending on showing everyone this but I- I’ll roll with it here um so there are two ways of interacting with the SDN controller um one is you can just send kernel commands so this is some test flows that I set, this is my oh s**t flow that deletes all of these SDN controller so I can stand it back up if uh something breaks during the talk. Um but uh or what I’ve done is you can interact with them through Python. So this is some code I wrote uh that actually interacts and sends flows to the switches that I’ll be uh demonstrating a little bit later. So yes the AP- it’s a restful API um you can pull whatever information you want on the network and push whatever updates you want to your SDN controller from there. Somebody over here? Yes sir? >>[inaudible off-mic question] >>I’m sorry? [inaudible off-mic comment] I will not be talking about a ton of security vulnerabilities in openflow, no. Um there are ways to attack openflow and there are problems with it um for one, one thing that uh that myself and my partner discovered was the- the packets from openflow- in the openflow protocol are very predictable and so you can begin to discern what packets and what kind of network it’s on if you have access to control channel traffic. Um there’s no padding inside the packets, they have a fixed size, so you can begin to uh to identify what packets are going across and identify the scope of the network um potentially even start building rainbow tables if you start cracking some of those packets. So those are uh a couple of problems, there’s no- there’s no randomness inside the packets is is one of the- one of the issues with it but this one I’m- it’s a little- it’s a little more leaning blue team, uh this side in talking about how we can defend our network and how SDN can- can help us in many ways so I will move on now um. Close this out. [mouse clicking] Oops. So, why do- why do we care about this? Um what have we- what have we learned so far, who cares about SDN? Well, so, one of the cool things, is we now have absolute control over every aspect of traffic, layer 1 through layer 7 so we can, we can view every bit of trakif- traffic, monitor it um, react to it in- in any way possible because we now have complete insight into everything depending on on how much you want. Um you can tr- apply traffic policies as we discussed to users and groups of users and floors in your building um that that all can be applied and they can only be allowed access to what they need to- what they need access to. Um once again flow tables can be created within flow tables to create dynamic decisions of what what we want how we want traffic to behave at at really every layer of the OSI model. So those are some cool cool things about the level of control and monitoring that we have that’s really uh that’s that’s really been a game changer with- within SDN. So a couple of the use cases for security and why this matters there is what- what are users actually doing um why do our users and not even our users, but our uh our servers, our cloud systems, who are they actually talking to? And why do they need to be- why do they need to be sending traffic that way? Um one great example of a- of a policy is, say your company has a p- put out a policy that we only allow our servers to talk to internal DNS, I’m sure that’s a policy at many many of your companies. How many of your companies though is that really working and applied globally? Or if you go into your your Splunk or whatever your sim is and do a search on 53 and see how many other uh DNS servers you’re calling out to. With SDN you can identify a DNS packet no matter what the server is and rewrite it to call to your DNS server within the traffic policy itself and so you no longer have to really- like obviously you want your stuff configured properly but at this point you could overwrite it and fill in your own information and ensure that all traffic queries your own DNS server um as you can rewrite the content da- of the packet you can rewrite the uh source and destination IP and uh and mac addresses you can totally totally spoof your own systems so that they only call to what you want them to. Um how do you allow- limit access to vendors and third party folks that need to connect to your network? You have some- some machinery that needs a vendor connected to do troubleshooting and debugging. How do you ensure they’re only doing what they’re supposed to? Um VLAN segmentation is is okay at best um firewalling them off i- requires changes in firewall rules and lots of uh lots of dy- uh manual input to try to meet each vendor’s needs um this can- this can do it dynamically in many ways. And uh and then how do you handle BYOD um internet of things devices in your network, um how do you ensure they’re properly sandboxed off and only having the access their- they need? Um so these are all security use cases where- where SDN can come in very handy and can fill a lot of those gaps. Time check here, okay. So let’s go into a little more of the- of the security side of things here. With the dynamic control we have over- over some of these things um what does that, what does that provide us on a security side? Well in many cases we can do location based access control now from an SDN because you know where all your switches are, you know what users are connecting to them, and uh you can use that in conjunction with many other factors to actually have provision network resources based on a user’s location uh even within your building so with what we’re gonna show- what I’m gonna show in a minute here uh with a big data uh security type model kind of moving away from the- the sim and moving into a big data model the data lake that you collect can have badging data, it can have video feeds, it can have any amount of security data about your network, and the SDN controller can actually look through that and pinpoint a user’s location and pinpoint the access that they’re allowed to have, so it can say, “Hey, this user just badged into uh into San Francisco uh why did he log into y’know Dallas and why did his why did he not- we not see him on the security footage in San Francisco?” and it can put all that together and and pinpoint where a user is in many cases or grant them access. So the legal team is allowed certain access to certain resources that HR for example is not allowed to. Um that could easily provisioned just from an infrastructure side long before your access control and your file sharing and whatever other security measures you have in place I’m talking in an infrastructural level you can control access to those- to those sorts of things. Um once again security tool uh security-tool-mageddon is what I- what I like to call it. You go over to the uh go over to Black Hat you go over to any of those places and you see infinity of security tools and in many cases um this vendor agnostic type of deployment can- can answer the the call of some of the security tools and and reduce the number of security tools you need. Um as we said, using patterns within your network and uh and mas- mission learning, you can start looking at bandwidth consumption and application usage, account behaviors and actually provision network, or limit network resources based on those. How many of you have heard of Apache Spot? Not a whole lot, it’s a fairly new project um it was uh started as an Intel project um that they wanted to use to okay thank you um that Intel wanted to use to demonst- to handle the massive massive amount of data that they’re- they’re handling on a daily basis. And so uh Apache Spot was kind of their- their answer to to solving some of these- some of these problems. And they’ve since moved it into the open source and it recently- wi- it was about two years old and uh has recently become uh an Apache incubating project um I am not involved in the Apache Spot project, I just thoroughly enjoy it and quite honestly uh much of this uh next portion could not have been done without a lot of the help from the dev team there um they were phenomenal working with me uh the- the team there from Intel on on getting this done. So what is Apache Spot? It is a- this is the uh the kind of verbiage from their- from their site, it’s a community-driven project providing advanced analytics and comprehensive von- uh visibility across all security data using an open, scalable platform. It is based on hadoop um and they’re currently working on uh on multiple different ways of ingesting multiple different types of data. So initially the- this Spot ingests uh various various network telemetry such as uh netflow or sflow data, um PCAP files, DNS information, proxy information, and uh and ultimately really able to ingest user information log-ins, user behavior all that sort of thing can just be ingested into their- into their data lake. And that’s where it goes into their ingest framework. Um they’re working on sp- uh soon to deploy spark streaming to allow large- larger quantities of data than they currently do, but it’s all built on Python, very easy to understand um very easy to code to. They then applied their machine learning model to it to determine patterns in the network data and uh and find find outliers and from there um they their op operational analytics portion actually evaluates that and preven- presents that to the uh to the analyst. So let’s check it out here. So this is uh this is kind of the network architecture I’m gonna use for this particular demo. Um right now, let me zoom in on it. So right now there’s a- there’s the kind of top of the rack switch, on each- on each of the racks there is uh two attacker hosts um as you can see host1 and host2 there, and then are- we have a honeynet here which is our spoof network that uh that we’re gonna make attackers think they’re in our real network but they’re actually not so that is designated by Winnie the Pooh um whoops I need to go over here. Make sure all my stuff cleared out. Perfect. Hmm [mouse clicks] so let me walk you through the Spot tool real quick here. So this is uh this is Apache Spot, this is what the dashboard looks like here. And uh and as you can see there are any number of of data entries here these are- uh the orange ones or yellow ones are signifying public IP addresses, and the blue ones are signifying internal IP addresses. Um and this was just some sample data that we generated for the purpose of this talk. Um any one of these can be- can be uh investigated and so you can pull up any one of these flows for example and it will show you all the hosts communicating to that- to that system uh and of what types, what types of communication and what uh what sorts are. Over here there’s the uh suspicious flows this this identifies traffic that is anomalous in some way and uh and identifies things that- that should be of concern. Now let me refresh this really quick. So for example here this is a uh- this is a suspicious flow, our our 10 dot zero dot zero dot one was identified as a suspicious attacker and uh and so you can see various types of enumeration attacks going on down here in the uh in the window and you can you can score each of the types of attacks uh based on your environment and so 10 dot 1 uh 10 0 0 0 1 was here sending all sorts of of weird things to our uh to our victim at 10 0 1 2 8 1 0 3. Now where that come in with SDN is the integration with that sort of architecture and uh and the SDN infrastructure and so what this allows is for that attacker to be identified and then action to be taken now I’m doing it manually here but in many cases you could do this very easily do this dynamically uh there’s certain behavior that you never ever wanna see on your network and you can immediately um do any number of things, send flows to the switches um based on that. So let me stand up my Mininet here. Doo doo doo. [mouse clicks] I am running very low on time here so we’re gonna blast through this. Um what we’re what we’re showing here is we can now send where are we Apache Spot? Um we can now send flows to the switches so I’ll just skip to the uh to the juicy one here say there’s this suspicious IP address is this 10 uh 10 0 0 1 here I want to investigate it and I want uh this particular IP I don’t want to block his access because as soon as his access is blocked, he- games up, um the attacker knows that- that we’re in. So what I can do is submit flows to the- to the SDN and actually honeypot that host and rewrite all of his uh all of his traffic so he thinks that he is in a different- is in a different network. Pull this up here gotta rush through this here. So as you can see here um you remember the uh the topology that I showed previously um basically what this has done here is it’s injected flows that have made the topology connect here it’s not physically connected but to the attacker’s point of view, they’re actually talking, so any traffic that he sends, that’s triggered by him speaking to another host, he’s immediately transparently redirected here. So his traffic as soon as it hits this switch is uh is rewritten with a new IP address, new subnet, and these switches all know how to handle that malicious subnet, so they’re added to a malicious type of subnet, these switches know how to handle it and immediately redirect it to our honeynet which is down here and that honeynet now can handle you can stand up VMs you can dynamically actually stand up whatever you want around that attacker and make him think he’s actually in your network, and in reality he’s not, he’s he’s just being very closely watched. And so this is all done though at an infrastructure level, this is not- this doesn’t require agents on computers, this doesn’t require anything other than the SDN infrastructure and so detecting those types of attacks um there are various plug ins um Intel’s currently working on the uh open security controller, different things that that can plug into this that can give this machine learning model this kind of dynamic knowledge to redirect traffic on an infrastructure level. And so when I said SkyNet can now fight back uh that’s exactly what this means, this- this is the network infrastructure actually taking charge of itself uh this isn’t a- this isn’t a software application running, this isn’t uh anything else, this is actually the infrastructure uh protecting itself. Now before I got uh Oscar’d off the sgae here, um finally a helpful SDN tool now I don’t mean there’s no other helpful SDN tools I just mean finally this is my last slide. Um this takes S flow information from the network and writes it to a Mininet topology and then communicates those flows to the controller. So basically you can translate any network into an SDN, even a lab network, even a- wh- whatever you want at home uh that you wanna test this out. I- I was trying to find out good ways to migrate to SDN and there’s not a lo- not any good opensource ways of migrating from a traditional network to an SDN and so that’s where this is supposed to come in handy. Um this will actually take you jus- take your regular Sflow netflow information you’re sending from your switches point it at uh at this little application, and it will start building Mininet topologies based on on that and sending those flows to a controller and those flows by the way don’t have to be sent to a Mininet, they can definitely be pointed at a regular controller and you can actually migrate- please don’t do this in production and then call me and like [laughter] in theory you can migrate a production network with this tool uh I wouldn’t recommend it but uh but check it out uh- eh- my issue is I was trying to think of a creative name for it, so it- it takes Sflow information, writes it to a Mininet topology, FloWrita, it it just made sense [laughter] [applause] so anyway, uh that’s all I got folks, are there any questions before- before I get booed off the stage here? [applause] Any questions? Wonderful. Well thank you so much I appreciate it, I’ll be around here afterwards I’d love to- I’d love to talk, thank you [applause]