00:00:00.167-->00:00:05.973 >>Welcome! Um, I asked for a, uh a, I asked for a for a two hour block and I got a 45 minute 00:00:05.973-->00:00:10.978 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 00:00:15.549-->00:00:20.053 been breaking things, hacking things since I was 12. Many apologies to the uh, the Hemet 00:00:20.053-->00:00:25.058 Public Library in Southern California, their uh their poor networks took a beating from 00:00:25.058-->00:00:29.630 young uh young me. Um and so it's especially special for me to a be speaking up here 00:00:29.630-->00:00:34.067 speaking to you all because you all growing up you all were rock stars to me like this is this is 00:00:34.067-->00:00:38.839 this is a the pinnacle of of where I wanted to be and never thought I would be so thank you 00:00:38.839-->00:00:43.410 very much for having me, I appreciate it. [Applause] I'm I I love this stuff I'm currently 00:00:43.410-->00:00:48.415 a a consulting network security architect is kinda of the box that I would put myself in. Um I 00:00:54.087-->00:00:59.793 uh work for an awesome company called Protiviti and I get to go around uh the country uh to 00:00:59.793-->00:01:06.667 various companies and break them um make them you know worry about themselves a little bit 00:01:06.667-->00:01:10.437 and then uh and then go in and help them and and help fix some of the problems that we find and 00:01:10.437-->00:01:15.409 some of the issues that we see there uh I absolutely love what I do. Um little bit about what 00:01:15.409-->00:01:20.347 we're talking about today and why why I think this talk is important. So software defined 00:01:20.347-->00:01:24.952 networking is is no longer a brand new technology. I'm not coming here to tell you about 00:01:24.952-->00:01:29.723 this blu- new bleeding edge technology that is just being discovered um as some of you 00:01:29.723-->00:01:34.361 have seen, software defined networking has been around a while. Um, it's now, it's now in 00:01:34.361-->00:01:38.532 in use in many large companies however there's very little presence of software defined 00:01:38.532-->00:01:43.036 networking talks and security related software defined networking talks specifically uh 00:01:43.036-->00:01:47.874 among these communities I am the second person ever to talk on software defined networking at 00:01:47.874-->00:01:52.546 Def Con um and last year another a team of researchers were some of the first ones to talk about 00:01:52.546-->00:01:57.384 it at Black Hat. Um, SDN has been around for years. And why, why is this not getting more 00:01:57.384-->00:02:00.721 visibility and so we're not going to, I'm not going to assume any knowledge here so 00:02:00.721-->00:02:05.192 we're gonna go through the start at the beginning and uh and show you exactly what what a software 00:02:05.192-->00:02:09.863 defined network looks like um, I'm breaking all rules of tech talks and not doing only one 00:02:09.863-->00:02:14.868 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 00:02:14.868-->00:02:19.873 goes. Moving on. Um, why Software Defined Networks? Why do we, why do we care, why do we 00:02:22.075-->00:02:26.947 need them, well as many of you know, networks have been around a very long time, and not much 00:02:26.947-->00:02:31.952 has changed, uh in a very long time. The uh TCP IP Stack, you can go buy those awesome two 00:02:34.321-->00:02:39.793 volume books that many of you are probably familiar with um on the TCP IP Stack, read those 00:02:39.793-->00:02:44.498 today they were written how many ever years ago and they are still just as relevant today. 00:02:44.498-->00:02:49.803 Because not much has changed. However the the architecture that we're using over the top of 00:02:49.803-->00:02:54.941 these networks has changed drastically with cloud migrations and uh and new types 00:02:54.941-->00:03:00.113 of networking, virtualization, lots has changed and networks in many cases have not kept up. Uh 00:03:00.113-->00:03:06.553 from a security perspective, for why can Alice and Bob for example working on the the same 00:03:06.553-->00:03:11.058 floor of a company's computers talk to each other? There's no reason for that. At no point 00:03:11.058-->00:03:15.195 should two people in in two separate cubicles computers really need to ever talk to each 00:03:15.195-->00:03:19.199 other. They have their certain resources they go to, and they should be limited to those. 00:03:19.199-->00:03:23.804 However, networks are designed to make things communicate. And so that's just what they do, and 00:03:23.804-->00:03:27.340 they do it well um, so in that way they, they work too well. Things are talking that 00:03:27.340-->00:03:31.111 shouldn't be. Um and along the same lines, firewall rule lists are starting to get out of 00:03:31.111-->00:03:37.184 control. Um, in addition, they don't they don't work well enough. Pervising network uh 00:03:37.184-->00:03:41.788 resources is expensive, time consuming and it's very difficult how do you know when 00:03:41.788-->00:03:46.526 you are deploying a re- uh a new a new system a ne- a new server how much bandwidth to allot 00:03:46.526-->00:03:51.164 that? You're stuck with a fixed amount of bandwidth giving that to that particular system un 00:03:51.164-->00:03:55.502 infrastructure deployment, is very expensive for those of you working on the infrastructure 00:03:55.502-->00:04:00.073 side, I don't know how many of you of- have deployed a nexus switch lately, um they get a 00:04:00.073-->00:04:05.078 little pricey so its pricing are going up, devices are getting more complicated, and uh and and 00:04:07.080-->00:04:11.852 how does this all translate as we move to the cloud? Well I'm hopefully gonna demonstrate a 00:04:11.852-->00:04:17.591 little bit of the cloud side here as my demos are all are all place um in the cloud. So. 00:04:17.591-->00:04:22.596 Little bit about software defined networking, so the core, the core behind software defined 00:04:25.532-->00:04:30.504 networking, the logic there is moving the control plane outside and the data plane outside of 00:04:30.504-->00:04:37.310 the devices. So our network devices now become a lot dumber. And the logic the the brains 00:04:37.310-->00:04:41.081 behind it is now the software defined networking controller. Uh that's sits sits at the top 00:04:41.081-->00:04:45.819 of the network so the controller's whats makes the decisions, for the switches, and 00:04:45.819-->00:04:48.755 if the the switches don't know how to handle something they ask the controller. And we'll go 00:04:48.755-->00:04:55.162 into more detail on that a little bit later Um well, I do want to make clear this is not 00:04:55.162-->00:05:00.567 network functions virtualization. So even in AWS you can see, you can see you can 00:05:00.567-->00:05:05.872 download an AMI for brocade switch, uh brocade routers, juniper firewalls, that is 00:05:05.872-->00:05:09.976 network functions virtualization, that's actually taking the the network hardware 00:05:09.976-->00:05:14.080 and virtualizing it. That's not what this is, this is a completely different and those 00:05:14.080-->00:05:17.584 can integrate with software defined networking, but software defined networking is is 00:05:17.584-->00:05:22.722 dramatically different from that and I"ll show you a what I mean by that here in just a moment. 00:05:22.722-->00:05:26.359 How many folks in the audience have interacted with software defined networking or know that 00:05:26.359-->00:05:31.131 it is in place in your companies? Look look around, there's a there's a solid amount 00:05:31.131-->00:05:35.168 of hands up right now so I'm really glad you are all here and uh and I look forward to 00:05:35.168-->00:05:40.907 interacting with you after the talk or during the questions here. So, just to a quick 00:05:40.907-->00:05:44.978 overview of what software defined networking is and how it works. First of all, what- 00:05:44.978-->00:05:50.617 what's out there? So there are uh closed sourced and open sources versions, um of course 00:05:50.617-->00:05:56.323 Cisco has the uh has the closed source one. Um and I say that as a as a Cisco network engineer in 00:05:56.323-->00:06:01.862 my past uh I I I enjoy Cisco soft but Cisco and VMware have done their own sort of closed 00:06:01.862-->00:06:06.066 source proprietary versions of it. They work- they work quite well. The open sourced companies 00:06:06.066-->00:06:11.071 have uh have used open source openflow controllers that use um all open source protocols and uh 00:06:14.140-->00:06:19.846 and their API's allow you to integrate things with um, um like I said before not a new 00:06:19.846-->00:06:23.850 technology. Uh go onto LInkedIn and do a search for software defined networking and you'll 00:06:23.850-->00:06:29.623 see how many companies are using it. Um it's a it's a lot..... Google, Amazon, Facebook, NSA uh 00:06:29.623-->00:06:33.760 and most telco's most of the 5G systems that are getting rolled out are being rolled out uh 00:06:33.760-->00:06:38.765 within a software defined networking architecture. Closed source or open source all 00:06:44.504-->00:06:48.208 software defined SDN architecture is going to look very very similar to this. So 00:06:48.208-->00:06:53.179 it's divided into three real uh segments. The top segment is the application layer and that's 00:06:53.179-->00:06:59.152 where your uh your business applications can interact with the SDN controller to provision 00:06:59.152-->00:07:03.657 network resources or monitor network traffic in any way they want. And that's done through 00:07:03.657-->00:07:09.095 API calls to the uh to the control layer which actually holds the SDN controller And 00:07:09.095-->00:07:12.565 I'll demonstrate the capabilities of that here with the tool that uh that I worked 00:07:12.565-->00:07:16.970 with some folks on on creating for this purpose After the control layer is the 00:07:16.970-->00:07:22.642 infrastructure layer. The that in between there is the openflow protocol where the, openflow 00:07:22.642-->00:07:27.814 controller or this SDN controller communicates with the switches. What's cool about this 00:07:27.814-->00:07:33.386 is when deployed in a uh- in a sec- in a recommended scenario, the control channel between the 00:07:33.386-->00:07:37.190 controller and the switches is actually on a completely separate um is physically 00:07:37.190-->00:07:42.395 separated from the data channel with where the switches actually go here posts um at the bottom 00:07:42.395-->00:07:47.701 And so it's it's with that kind of setup it's it's almost impossible without manipulating 00:07:47.701-->00:07:52.072 the firmware of the switches to jump into the control channel. And unfortunately because I uh 00:07:52.072-->00:07:56.943 I'm short on time today, I'm not able to go into a whole lot of the red teaming side of things 00:07:56.943-->00:08:01.514 um with with the uh SDN controller but there's some really cool really cool things 00:08:01.514-->00:08:05.652 about uh compromising SDN controllers and taking over control channels. I spoke a 00:08:05.652-->00:08:11.958 little bit on that at uh at Shmoocon last year So core concepts. First of all I 00:08:11.958-->00:08:16.196 apologize for the graphic, uh this slide was really bare without it and so I just Google 00:08:16.196-->00:08:22.635 image searched and that was the first thing that came up when I typed in flow and I was drunk 00:08:22.635-->00:08:26.506 and it ended up in there so [laughter] Core concepts of SDN. The controller sends flows which 00:08:26.506-->00:08:31.444 look a lot like ACL's to switches. Uh the switches then make decisions based on those 00:08:31.444-->00:08:35.315 flows and forward traffic to its various destination based on that. And we'll talk more on 00:08:35.315-->00:08:40.453 flows in just a second. Um, if a switch doesn't have a flow that matches a certain type of packet 00:08:40.453-->00:08:44.791 it asks the controller and then the controller can either tell it, "hey, drop it" or, "here's 00:08:44.791-->00:08:48.661 the new instructions start sending those flows this way" or it can send any number of 00:08:48.661-->00:08:53.166 instructions to the switch on how to treat that flow. And once again, we'll, we'll talk about 00:08:53.166-->00:08:57.704 more about that in a sec. Or you can finally just have a drop so it's almost like a- like a 00:08:57.704-->00:09:01.975 firewall rule set so at the very bottom is your dropset and if if nothing matches any of the flows 00:09:01.975-->00:09:07.313 already in the switches, just kill it, it doesn't belong there. This is what a flow looks 00:09:07.313-->00:09:12.318 like. Inside inside a switch. So, uh first is the rule which is the match information. And 00:09:16.022-->00:09:21.828 that tells the switch what to look for in the packet. Now natively it supports pretty much 00:09:21.828-->00:09:26.933 layer one through layer four, so any it can match anything within the packet all the way from what 00:09:26.933-->00:09:33.373 port it came into on the switch to the mac address to the uh to the VLAN, to the IP address, 00:09:33.373-->00:09:38.812 anyway all the way up to port and protocol. Once you start integrating uh different 00:09:38.812-->00:09:43.183 programs, different business programs as we discussed through the APIs it can now look all the 00:09:43.183-->00:09:47.987 way through layer 7 and you can actually find program data within the packets and match 00:09:47.987-->00:09:53.259 that within side inside an SDN controller So that first blue section there, I think that's 00:09:53.259-->00:09:59.365 blue, I'm color blind uh is the- is the match area. The next part is the actions so what action 00:09:59.365-->00:10:06.272 does that is that switch gonna perform on that packet once it it matches that criteria? Lots 00:10:06.272-->00:10:10.076 of lots of possible opportunities and many of them will cause your ears to perk up 00:10:10.076-->00:10:14.414 a little bit as we'll demonstrate later um one is it can forward packets to ports its 00:10:14.414-->00:10:18.518 says, "Hey if I see things inside port forward it to that port" or "if I see it coming in 00:10:18.518-->00:10:22.222 from this IP address, forward it to that IP address." You can make it have very traditional 00:10:22.222-->00:10:28.728 switching um behaviour if you wish. Some other cool things though is you can overwrite data 00:10:28.728-->00:10:34.133 inside the packet. So, you can have your hosts believing they're on one sub net when in 00:10:34.133-->00:10:38.071 reality, as soon as their traffic hits the switch all their sub net all their IP 00:10:38.071-->00:10:43.209 address information is rewritten and sent someplace else. So you can now spoof hosts anywhere in 00:10:43.209-->00:10:47.780 the network. You can move hosts wherever you want in the network and uh and you can do this to 00:10:47.780-->00:10:54.554 either secure or or actually attack a network as we'll show here shortly. Um, and many of 00:10:54.554-->00:10:58.858 the things so the normal processing pipeline is is "hey switch Behave like a switch" uh 00:10:58.858-->00:11:05.198 "just do do your switching thing. If something weird comes up, send it to the controller", 00:11:05.198-->00:11:11.538 and then uh and then obviously dropping packets are uh are another option there So let- I'm 00:11:11.538-->00:11:16.676 gonna fire up uh an SDN here and we can actually we can actually look at it. Let me get set up 00:11:16.676-->00:11:21.681 here [mic noise] [speaker exhales] All right. The VPN disconnected so I just need a 00:11:33.993-->00:11:38.998 minute for that to stand up. There we go [mouse clicks] So, here is the openflow controller 00:11:49.676-->00:11:54.180 I chose to use the floodlight controller today, um as I said before, there are there are many 00:11:54.180-->00:12:00.920 other vendors. This one is uh- is an open sourced product of the big switch, um, company. 00:12:00.920-->00:12:05.091 It's uh it's very stable it's a newson production and uh big switch has all kinds of cool 00:12:05.091-->00:12:09.162 things you can add into it if you so choose. Uh let me just give you a short walk through of 00:12:09.162-->00:12:14.000 this. So um, here on the dashboard you have a- you can have multiple controllers so you 00:12:14.000-->00:12:18.438 can actually have kind of a split brain type logic for your network. If you choose where- 00:12:18.438-->00:12:21.441 where trollers- controllers can communicate to each other about different portions of your 00:12:21.441-->00:12:27.413 network, and uh that can provide some very high level type of segmentation as well high 00:12:27.413-->00:12:33.653 availability. Um, at ah- this will show you switches hosts as soon as we set it up. But a 00:12:33.653-->00:12:38.825 couple of other things that I want to point out that we are not going to uh get into today 00:12:38.825-->00:12:44.564 is uh, you can perform um, firewalling at the controller level. So, before the controller 00:12:44.564-->00:12:49.769 even performs logic, um, internally on the uh on the switches you can immediately 00:12:49.769-->00:12:53.806 define "Hey controller. These two things should never be allowed to talk" or "this 00:12:53.806-->00:12:58.711 network should never be allowed to talk to this network". Um, and that's possessed prior to uh 00:12:58.711-->00:13:03.650 prior to any other logic done in the controller. Um, and it can be done in a more of a-, more of 00:13:03.650-->00:13:08.287 a proactive way so you can actually be sending dynamic firewall rules to the controller 00:13:08.287-->00:13:13.292 as it sees uh, as it sees malicious traffic. Um, let me stand up our our Mininet here. 00:13:15.428-->00:13:20.733 So , Mininet is a great program um, how many of you have heard of Mininet or worked with 00:13:20.733-->00:13:25.405 Mininet? Okay, handful of you, I I highly recommend it to everyone. Even if not for SDN, 00:13:25.405-->00:13:30.410 it's a great tool. So, um, [exhales] I don't want to type all this out so I'm just gonna 00:13:37.684-->00:13:42.689 copy and paste it here. Oops. So what Mininet does is it simulates a network of of 00:13:48.261-->00:13:53.266 switches of any real type you want. And, uh and in this case it can also simulate uh SDN 00:13:56.035-->00:14:02.008 switches. So what I've done here, um, is created actually let me... let me do a little 00:14:02.008-->00:14:07.013 cooler network this one's not very fun. [Exhales] [Hums] Let's see, yeah, let's do this one. 00:14:15.254-->00:14:20.259 So, you can build uh custom topologies. They're, they're really their possibilities are 00:14:22.662-->00:14:27.834 endless. And it stands up hosts underneath those switches. So, once you stand up your, once you 00:14:27.834-->00:14:32.705 stand up your switches it will also connect hosts to them and uh and you can interact with 00:14:32.705-->00:14:37.310 those hosts in any way you choose as you'll see here. So, this is gonna take a minute for 00:14:37.310-->00:14:44.083 it to discover everything. So as you can see now, um we have 9 switches connected to the SDN 00:14:44.083-->00:14:49.088 and 131 hosts. All of which are run as uh mini bash instances on your on your host Mininet 00:14:51.457-->00:14:55.294 machines. So you can go in on them, you can end map from them, you can run anything you can 00:14:55.294-->00:15:01.267 access from BASH you can do on those- on those hosts, which is super cool. So this is the 00:15:01.267-->00:15:06.272 network we just stood up. So there we are. Um, and right now as you can see, oooo, squid. Uh 00:15:17.416-->00:15:22.455 as you can see, there are uh there's a core switch with um basically what the topology I 00:15:22.455-->00:15:25.458 like to use kind of simulates more of a data center environment, so this- you can 00:15:25.458-->00:15:30.029 see it as almost a- as a core switch and then each one of the other switches around there are 00:15:30.029-->00:15:33.800 top of the rack switches with with hosts below them is how I like to visualize it and we'll 00:15:33.800-->00:15:37.036 go into that a little bit later when I show you some of the security functions of this. But 00:15:37.036-->00:15:43.009 uh once the SDN controller so let me show you a few of the flows inside the switches here. 00:15:43.009-->00:15:49.015 So right now the switches don't know much about their life so let's go into switch number 2 00:15:49.015-->00:15:54.787 here. So here's the flow table it has one single lonely flow in there and that means output to 00:15:54.787-->00:15:59.659 controller. Uh so the switch has no instructions right now, it doesn't know what it's doing, 00:15:59.659-->00:16:04.931 all it knows is, "Hey if I see a packet, immediately send it to the controller 'cause I have no 00:16:04.931-->00:16:10.870 idea what I'm doing." These 234 packets are LLD- DP packets which is a- a core functionality 00:16:10.870-->00:16:17.443 of um of S- of openflow which has some security implications in and of itself as you can 00:16:17.443-->00:16:22.815 imagine but that's what the controller uses, the controller sends LLDP p- LLDP broadcasts 00:16:22.815-->00:16:25.952 and that's how it actually knows that these hosts are connected and that these switches are 00:16:25.952-->00:16:29.922 connected, it's through LLDP. But as you know, it doesn't know any of the IP addresses of these 00:16:29.922-->00:16:35.094 yet because uh it's it's only used LLDP to discover them so let's let's go let's teach these 00:16:35.094-->00:16:41.100 switches some things. So I'm just gonna do ping all and so it has every host ping every other 00:16:41.100-->00:16:46.105 host and as that's going let's go back to our switches and we can now see that it's learning. 00:16:50.643-->00:16:55.781 It's now- the controller's now sending flows to these switches and telling it where to redirect 00:16:55.781-->00:17:01.587 these packets, so you can see this packet um it- they're given their priority um if we- if we 00:17:01.587-->00:17:05.758 go into the API you can actually see what the match conditions were um this particular one is 00:17:05.758-->00:17:12.031 only matching on uh on ethernet mac address so matching and instructions so "Hey if you see 00:17:12.031-->00:17:15.067 packets from here, send it out there, send it out there" and as you can see there's multiple 00:17:15.067-->00:17:20.172 pages uh 586 entries at the moment and that's just one switch so that's the uh that's 00:17:20.172-->00:17:26.045 one of the leaf switches um the core switch will probably have some fewer ones because it's- 00:17:26.045-->00:17:30.783 it's just managing all four- or five of those switches. So as you can see, that's what the 00:17:30.783-->00:17:36.689 flow table looks like um and within the uh within the uh floodlight controller you can 00:17:36.689-->00:17:41.127 actually add static flows and so here's what we talked about, which switch do you wanna put it 00:17:41.127-->00:17:45.865 on, ne- give it a unique name uh you can give it priority. So one of the other really neat things 00:17:45.865-->00:17:50.870 about uh about the the flow tables is you can create flow tables within flow tables like 00:17:52.939-->00:17:59.145 this flow table inception thing and uh and that allows you to actually have logic behind these 00:17:59.145-->00:18:05.451 flows. So for example you can say "Hey, I uh, I want this to be my user group, and I want all 00:18:05.451-->00:18:09.789 their traffic to be treated the same. I know all my users go to our three databases, they go to 00:18:09.789-->00:18:13.960 the internet, and they go to, y'know this file share somewhere" and you can have 00:18:13.960-->00:18:18.898 those- that that logic programmed in as a single flow and so when the it goes through 00:18:18.898-->00:18:24.537 the switches, it identifies a secondary flow table and says, "Oh this is a user- this this IP 00:18:24.537-->00:18:28.641 address or this host is part of the user group. Let me toss them over to this flow table and use 00:18:28.641-->00:18:33.079 that logic um in there" So you can actually nest and create almost uh like if then 00:18:33.079-->00:18:38.851 statements within the flow tables. Uh you can sa- have active- you can change the rules 00:18:38.851-->00:18:43.356 whether they're active or- or not. Um so you can turn them on and off. You can also have rules 00:18:43.356-->00:18:48.361 that are set to timeout, which is awesome for example if you're doing large scale patching or 00:18:48.361-->00:18:53.265 data migration operations, you can have flows that will redirect traffic at night over- 00:18:53.265-->00:18:58.637 over different channels. So one of the cool things about SDN is uh loops. You're allowed to have 00:18:58.637-->00:19:03.576 loops in an SDN. Many of you network folks know that loops are uh- a horrible nightmare 00:19:03.576-->00:19:07.913 that Spanning Tree thankfully came along and saved us from most of the time and uh with 00:19:07.913-->00:19:13.586 SDN, SDN does not care. You can- you can have multiple uh links going to the same switch and it 00:19:13.586-->00:19:18.524 will load balance across them if you so choose, uh it won't loop across them or you can have 00:19:18.524-->00:19:22.762 dedicated physical links for specific types of traffic so the the possibilities are really 00:19:22.762-->00:19:27.033 endless. Connect all your switches in a full mesh, nobody cares. Um very cool 'cause you 00:19:27.033-->00:19:32.738 don't need Spanning Tree. Uh so once again these- these timeouts you can uh you can timeout the 00:19:32.738-->00:19:37.943 flows and have traffic redirected at certain times of day or direct based on load. So 00:19:37.943-->00:19:42.181 you can now load balance traffic dynamically because the SDN controller knows how much 00:19:42.181-->00:19:47.186 traffic is going across um that's that 3rd part that I'm getting into here. So that 3rd 00:19:51.924-->00:19:58.130 aspect here is the stats. That stats tracks the bandwidth, packet in, byte counters, how 00:19:58.130-->00:20:01.801 many times that flow was hit, all those sorts of things, and sends all that information to 00:20:01.801-->00:20:06.172 the controller which then aggregates it and can show your high bandwidth links, all of the 00:20:06.172-->00:20:11.911 uh any security issues, that sort of thing can be tracked through there. Um and that's how 00:20:11.911-->00:20:16.816 you can dynamically load balance your traffic around your uh around your switches. so let me 00:20:16.816-->00:20:21.821 go back here, close this out. Any questions about this- this first part first before I close 00:20:26.492-->00:20:31.497 things down here? Yes sir! >> [inaudible off-mic audience question] >>Excellent question, 00:20:33.499-->00:20:38.237 so with any pure SDN network uh oh I'm so- goo- good call, so the question was, where does 00:20:38.237-->00:20:42.675 routing fit in, um how do- how do you do routing, he mentioned routing protocols, EIGRP uh BPB, 00:20:42.675-->00:20:47.680 that sort of thing. Within an SDN uh a pure SDN, IP addressing as we know it today is obsolete. 00:20:53.385-->00:20:58.390 You don't need it really at all um it's a reference that helps us in many ways to identify 00:20:58.390-->00:21:02.795 switches because it's what we're used to, but you actually don't need it. However, where you do 00:21:02.795-->00:21:06.999 need it is when you're interacting with other networks and so the controller has plug 00:21:06.999-->00:21:12.004 ins for routing protocols and has I- IP or BGP logic has EIGRP logic and actually uh the 00:21:14.206-->00:21:17.510 floodlight controller has plug ins that- that do that and you just have to enable them and it 00:21:17.510-->00:21:23.816 does it natively and so as soon as a BGP packet comes in um the controller can actually handle 00:21:23.816-->00:21:29.688 it, respond, and keep a BGP connection alive for example uh through an SDN and so the the 00:21:29.688-->00:21:33.559 destination network or your service provider, doesn't know anything about it. Um within 00:21:33.559-->00:21:38.564 cloud uh environments it's very very similar so for example uh many folks here uh probably work 00:21:40.766-->00:21:46.572 on openstack, that sort of thing uh f- openflow works natively with openstack um with plug ins 00:21:46.572-->00:21:52.011 and can actually manage your traffic much like the VMWare NSX does on the back end and manage 00:21:52.011-->00:21:55.814 your traffic for all- whatever you stand up in openstack so that's- that's a really cool 00:21:55.814-->00:22:00.953 function of it and it- it all works natively in the cloud and in many cases uh you're actually 00:22:00.953-->00:22:05.157 using SDN when you're- when you have your VPCs running in AWS and you- you may or may not know 00:22:05.157-->00:22:10.162 it. Um any other questions before I move out of the demo here? Yes sir >>[inaudible 00:22:12.298-->00:22:18.370 off-mic audience member question] >>Yes! [inaudible] So yes, the uh, I wasn't intending 00:22:18.370-->00:22:25.211 on showing everyone this but I- I'll roll with it here um so there are two ways of 00:22:25.211-->00:22:28.981 interacting with the SDN controller um one is you can just send kernel commands so 00:22:28.981-->00:22:34.086 this is some test flows that I set, this is my oh s**t flow that deletes all of these SDN 00:22:34.086-->00:22:38.891 controller so I can stand it back up if uh something breaks during the talk. Um but uh or 00:22:38.891-->00:22:43.963 what I've done is you can interact with them through Python. So this is some code I 00:22:43.963-->00:22:48.167 wrote uh that actually interacts and sends flows to the switches that I'll be uh demonstrating a 00:22:48.167-->00:22:52.238 little bit later. So yes the AP- it's a restful API um you can pull whatever information you 00:22:52.238-->00:22:56.242 want on the network and push whatever updates you want to your SDN controller from there. 00:22:56.242-->00:23:01.180 Somebody over here? Yes sir? >>[inaudible off-mic question] >>I'm sorry? [inaudible off-mic 00:23:07.853-->00:23:11.090 comment] I will not be talking about a ton of security vulnerabilities in openflow, no. 00:23:11.090-->00:23:16.895 Um there are ways to attack openflow and there are problems with it um for one, one thing 00:23:16.895-->00:23:21.600 that uh that myself and my partner discovered was the- the packets from openflow- in the 00:23:21.600-->00:23:26.438 openflow protocol are very predictable and so you can begin to discern what packets and what 00:23:26.438-->00:23:30.676 kind of network it's on if you have access to control channel traffic. Um there's no padding 00:23:30.676-->00:23:36.282 inside the packets, they have a fixed size, so you can begin to uh to identify what packets are 00:23:36.282-->00:23:40.085 going across and identify the scope of the network um potentially even start building 00:23:40.085-->00:23:44.156 rainbow tables if you start cracking some of those packets. So those are uh a couple of 00:23:44.156-->00:23:48.093 problems, there's no- there's no randomness inside the packets is is one of the- one of the issues 00:23:48.093-->00:23:52.064 with it but this one I'm- it's a little- it's a little more leaning blue team, uh this side 00:23:52.064-->00:23:57.369 in talking about how we can defend our network and how SDN can- can help us in many ways so 00:23:57.369-->00:24:02.308 I will move on now um. Close this out. [mouse clicking] Oops. So, why do- why do we care about 00:24:21.493-->00:24:26.498 this? Um what have we- what have we learned so far, who cares about SDN? Well, so, one of the 00:24:28.600-->00:24:33.238 cool things, is we now have absolute control over every aspect of traffic, layer 1 00:24:33.238-->00:24:38.243 through layer 7 so we can, we can view every bit of trakif- traffic, monitor it um, react to 00:24:41.814-->00:24:45.217 it in- in any way possible because we now have complete insight into everything 00:24:45.217-->00:24:50.356 depending on on how much you want. Um you can tr- apply traffic policies as we discussed 00:24:50.356-->00:24:57.129 to users and groups of users and floors in your building um that that all can be applied and they 00:24:57.129-->00:25:02.768 can only be allowed access to what they need to- what they need access to. Um once again 00:25:02.768-->00:25:07.272 flow tables can be created within flow tables to create dynamic decisions of what what 00:25:07.272-->00:25:12.111 we want how we want traffic to behave at at really every layer of the OSI model. So those are 00:25:12.111-->00:25:17.483 some cool cool things about the level of control and monitoring that we have that's really uh 00:25:17.483-->00:25:21.720 that's that's really been a game changer with- within SDN. So a couple of the use cases for 00:25:21.720-->00:25:26.492 security and why this matters there is what- what are users actually doing um why do our 00:25:26.492-->00:25:31.764 users and not even our users, but our uh our servers, our cloud systems, who are they 00:25:31.764-->00:25:36.502 actually talking to? And why do they need to be- why do they need to be sending traffic that 00:25:36.502-->00:25:42.241 way? Um one great example of a- of a policy is, say your company has a p- put out a policy that 00:25:42.241-->00:25:46.712 we only allow our servers to talk to internal DNS, I'm sure that's a policy at many many of 00:25:46.712-->00:25:52.618 your companies. How many of your companies though is that really working and applied globally? Or 00:25:52.618-->00:25:57.022 if you go into your your Splunk or whatever your sim is and do a search on 53 and see how many 00:25:57.022-->00:26:03.896 other uh DNS servers you're calling out to. With SDN you can identify a DNS packet no matter 00:26:03.896-->00:26:08.901 what the server is and rewrite it to call to your DNS server within the traffic policy itself 00:26:11.236-->00:26:15.007 and so you no longer have to really- like obviously you want your stuff configured properly 00:26:15.007-->00:26:18.977 but at this point you could overwrite it and fill in your own information and ensure that 00:26:18.977-->00:26:24.416 all traffic queries your own DNS server um as you can rewrite the content da- of the packet you 00:26:24.416-->00:26:29.588 can rewrite the uh source and destination IP and uh and mac addresses you can totally 00:26:29.588-->00:26:35.994 totally spoof your own systems so that they only call to what you want them to. Um how do you 00:26:35.994-->00:26:40.199 allow- limit access to vendors and third party folks that need to connect to your network? You 00:26:40.199-->00:26:45.270 have some- some machinery that needs a vendor connected to do troubleshooting and debugging. 00:26:45.270-->00:26:50.809 How do you ensure they're only doing what they're supposed to? Um VLAN segmentation is is okay 00:26:50.809-->00:26:57.583 at best um firewalling them off i- requires changes in firewall rules and lots of uh lots of dy- 00:26:57.583-->00:27:03.255 uh manual input to try to meet each vendor's needs um this can- this can do it dynamically in 00:27:03.255-->00:27:09.394 many ways. And uh and then how do you handle BYOD um internet of things devices in your 00:27:09.394-->00:27:13.665 network, um how do you ensure they're properly sandboxed off and only having the access 00:27:13.665-->00:27:17.970 their- they need? Um so these are all security use cases where- where SDN can come in 00:27:17.970-->00:27:22.975 very handy and can fill a lot of those gaps. Time check here, okay. So let's go into a little 00:27:29.715-->00:27:35.187 more of the- of the security side of things here. With the dynamic control we have over- 00:27:35.187-->00:27:39.725 over some of these things um what does that, what does that provide us on a security side? 00:27:39.725-->00:27:46.465 Well in many cases we can do location based access control now from an SDN because you know 00:27:46.465-->00:27:50.802 where all your switches are, you know what users are connecting to them, and uh you can use that 00:27:50.802-->00:27:55.107 in conjunction with many other factors to actually have provision network resources 00:27:55.107-->00:28:00.779 based on a user's location uh even within your building so with what we're gonna show- what 00:28:00.779-->00:28:07.219 I'm gonna show in a minute here uh with a big data uh security type model kind of moving away 00:28:07.219-->00:28:12.524 from the- the sim and moving into a big data model the data lake that you collect can have 00:28:12.524-->00:28:17.195 badging data, it can have video feeds, it can have any amount of security data about your 00:28:17.195-->00:28:22.334 network, and the SDN controller can actually look through that and pinpoint a user's location 00:28:22.334-->00:28:26.572 and pinpoint the access that they're allowed to have, so it can say, "Hey, this user just 00:28:26.572-->00:28:31.577 badged into uh into San Francisco uh why did he log into y'know Dallas and why did his 00:28:34.379-->00:28:38.216 why did he not- we not see him on the security footage in San Francisco?" and it can put all 00:28:38.216-->00:28:44.189 that together and and pinpoint where a user is in many cases or grant them access. So the legal 00:28:44.189-->00:28:49.194 team is allowed certain access to certain resources that HR for example is not allowed to. Um 00:28:49.194-->00:28:54.499 that could easily provisioned just from an infrastructure side long before your access control 00:28:54.499-->00:28:58.670 and your file sharing and whatever other security measures you have in place I'm talking in 00:28:58.670-->00:29:04.343 an infrastructural level you can control access to those- to those sorts of things. Um once 00:29:04.343-->00:29:08.647 again security tool uh security-tool-mageddon is what I- what I like to call it. You 00:29:08.647-->00:29:14.086 go over to the uh go over to Black Hat you go over to any of those places and you see 00:29:14.086-->00:29:20.025 infinity of security tools and in many cases um this vendor agnostic type of deployment can- 00:29:20.025-->00:29:24.329 can answer the the call of some of the security tools and and reduce the number of security 00:29:24.329-->00:29:29.334 tools you need. Um as we said, using patterns within your network and uh and mas- mission 00:29:31.937-->00:29:35.974 learning, you can start looking at bandwidth consumption and application usage, account 00:29:35.974-->00:29:40.278 behaviors and actually provision network, or limit network resources based on those. How 00:29:44.282-->00:29:50.822 many of you have heard of Apache Spot? Not a whole lot, it's a fairly new project um it was uh 00:29:50.822-->00:29:55.827 started as an Intel project um that they wanted to use to okay thank you um that Intel wanted 00:29:59.665-->00:30:05.037 to use to demonst- to handle the massive massive amount of data that they're- they're handling 00:30:05.037-->00:30:11.209 on a daily basis. And so uh Apache Spot was kind of their- their answer to to solving some 00:30:11.209-->00:30:14.646 of these- some of these problems. And they've since moved it into the open source 00:30:14.646-->00:30:19.851 and it recently- wi- it was about two years old and uh has recently become uh an Apache 00:30:19.851-->00:30:24.856 incubating project um I am not involved in the Apache Spot project, I just thoroughly enjoy 00:30:24.856-->00:30:28.827 it and quite honestly uh much of this uh next portion could not have been done without a lot of 00:30:28.827-->00:30:33.532 the help from the dev team there um they were phenomenal working with me uh the- the team there 00:30:33.532-->00:30:38.537 from Intel on on getting this done. So what is Apache Spot? It is a- this is the uh the kind of 00:30:40.872-->00:30:44.409 verbiage from their- from their site, it's a community-driven project providing advanced 00:30:44.409-->00:30:49.147 analytics and comprehensive von- uh visibility across all security data using an open, 00:30:49.147-->00:30:54.886 scalable platform. It is based on hadoop um and they're currently working on uh on 00:30:54.886-->00:30:59.791 multiple different ways of ingesting multiple different types of data. So initially the- 00:30:59.791-->00:31:04.730 this Spot ingests uh various various network telemetry such as uh netflow or sflow data, um 00:31:09.367-->00:31:14.873 PCAP files, DNS information, proxy information, and uh and ultimately really able to ingest 00:31:14.873-->00:31:19.010 user information log-ins, user behavior all that sort of thing can just be ingested into their- 00:31:19.010-->00:31:24.015 into their data lake. And that's where it goes into their ingest framework. Um they're working on 00:31:26.151-->00:31:31.289 sp- uh soon to deploy spark streaming to allow large- larger quantities of data than they 00:31:31.289-->00:31:35.327 currently do, but it's all built on Python, very easy to understand um very easy to code 00:31:35.327-->00:31:39.898 to. They then applied their machine learning model to it to determine patterns in the 00:31:39.898-->00:31:46.071 network data and uh and find find outliers and from there um they their op operational 00:31:46.071-->00:31:50.208 analytics portion actually evaluates that and preven- presents that to the uh to the 00:31:50.208-->00:31:56.248 analyst. So let's check it out here. So this is uh this is kind of the network architecture I'm 00:31:56.248-->00:32:02.687 gonna use for this particular demo. Um right now, let me zoom in on it. So right now there's 00:32:02.687-->00:32:07.559 a- there's the kind of top of the rack switch, on each- on each of the racks there is uh 00:32:07.559-->00:32:12.964 two attacker hosts um as you can see host1 and host2 there, and then are- we have a honeynet 00:32:12.964-->00:32:18.303 here which is our spoof network that uh that we're gonna make attackers think they're in our 00:32:18.303-->00:32:23.441 real network but they're actually not so that is designated by Winnie the Pooh um 00:32:23.441-->00:32:28.446 whoops I need to go over here. Make sure all my stuff cleared out. Perfect. Hmm [mouse clicks] 00:32:42.594-->00:32:47.899 so let me walk you through the Spot tool real quick here. So this is uh this is Apache Spot, 00:32:47.899-->00:32:54.406 this is what the dashboard looks like here. And uh and as you can see there are any number of of 00:32:54.406-->00:32:58.944 data entries here these are- uh the orange ones or yellow ones are signifying public IP 00:32:58.944-->00:33:03.048 addresses, and the blue ones are signifying internal IP addresses. Um and this was just 00:33:03.048-->00:33:08.153 some sample data that we generated for the purpose of this talk. Um any one of these 00:33:08.153-->00:33:14.793 can be- can be uh investigated and so you can pull up any one of these flows for example and 00:33:14.793-->00:33:19.497 it will show you all the hosts communicating to that- to that system uh and of what types, 00:33:19.497-->00:33:24.569 what types of communication and what uh what sorts are. Over here there's the uh suspicious 00:33:24.569-->00:33:29.608 flows this this identifies traffic that is anomalous in some way and uh and identifies 00:33:29.608-->00:33:34.613 things that- that should be of concern. Now let me refresh this really quick. So for example 00:33:37.015-->00:33:41.519 here this is a uh- this is a suspicious flow, our our 10 dot zero dot zero dot one was 00:33:41.519-->00:33:46.925 identified as a suspicious attacker and uh and so you can see various types of enumeration 00:33:46.925-->00:33:51.062 attacks going on down here in the uh in the window and you can you can score each of the types 00:33:51.062-->00:33:56.968 of attacks uh based on your environment and so 10 dot 1 uh 10 0 0 0 1 was here sending all 00:33:56.968-->00:34:03.074 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 00:34:03.074-->00:34:08.079 SDN is the integration with that sort of architecture and uh and the SDN infrastructure and so 00:34:10.382-->00:34:15.854 what this allows is for that attacker to be identified and then action to be taken now I'm 00:34:15.854-->00:34:20.258 doing it manually here but in many cases you could do this very easily do this dynamically 00:34:20.258-->00:34:24.396 uh there's certain behavior that you never ever wanna see on your network and you can immediately 00:34:24.396-->00:34:29.167 um do any number of things, send flows to the switches um based on that. So let me stand up my 00:34:29.167-->00:34:34.172 Mininet here. Doo doo doo. [mouse clicks] I am running very low on time here so we're gonna 00:34:41.379-->00:34:46.384 blast through this. Um what we're what we're showing here is we can now send where are we 00:34:50.088-->00:34:55.527 Apache Spot? Um we can now send flows to the switches so I'll just skip to the uh to the juicy 00:34:55.527-->00:35:00.966 one here say there's this suspicious IP address is this 10 uh 10 0 0 1 here I want to 00:35:00.966-->00:35:07.005 investigate it and I want uh this particular IP I don't want to block his access because as 00:35:07.005-->00:35:12.277 soon as his access is blocked, he- games up, um the attacker knows that- that we're in. So 00:35:12.277-->00:35:17.282 what I can do is submit flows to the- to the SDN and actually honeypot that host and rewrite 00:35:21.419-->00:35:28.293 all of his uh all of his traffic so he thinks that he is in a different- is in a different 00:35:28.293-->00:35:33.298 network. Pull this up here gotta rush through this here. So as you can see here um you remember 00:35:40.205-->00:35:45.110 the uh the topology that I showed previously um basically what this has done here is it's 00:35:45.110-->00:35:50.782 injected flows that have made the topology connect here it's not physically connected but to 00:35:50.782-->00:35:54.953 the attacker's point of view, they're actually talking, so any traffic that he sends, that's 00:35:54.953-->00:36:00.058 triggered by him speaking to another host, he's immediately transparently redirected here. 00:36:00.058-->00:36:05.997 So his traffic as soon as it hits this switch is uh is rewritten with a new IP address, 00:36:05.997-->00:36:09.968 new subnet, and these switches all know how to handle that malicious subnet, so they're 00:36:09.968-->00:36:13.538 added to a malicious type of subnet, these switches know how to handle it and immediately 00:36:13.538-->00:36:19.177 redirect it to our honeynet which is down here and that honeynet now can handle you can 00:36:19.177-->00:36:23.381 stand up VMs you can dynamically actually stand up whatever you want around that attacker and 00:36:23.381-->00:36:27.052 make him think he's actually in your network, and in reality he's not, he's he's just being 00:36:27.052-->00:36:31.089 very closely watched. And so this is all done though at an infrastructure level, this is 00:36:31.089-->00:36:36.061 not- this doesn't require agents on computers, this doesn't require anything other than the 00:36:36.061-->00:36:41.699 SDN infrastructure and so detecting those types of attacks um there are various plug ins um 00:36:41.699-->00:36:45.637 Intel's currently working on the uh open security controller, different things that that can 00:36:45.637-->00:36:50.008 plug into this that can give this machine learning model this kind of dynamic knowledge to 00:36:50.008-->00:36:54.712 redirect traffic on an infrastructure level. And so when I said SkyNet can now fight 00:36:54.712-->00:36:59.918 back uh that's exactly what this means, this- this is the network infrastructure actually taking 00:36:59.918-->00:37:04.589 charge of itself uh this isn't a- this isn't a software application running, this isn't 00:37:04.589-->00:37:09.494 uh anything else, this is actually the infrastructure uh protecting itself. Now before I 00:37:09.494-->00:37:14.499 got uh Oscar'd off the sgae here, um finally a helpful SDN tool now I don't mean there's no 00:37:20.772-->00:37:27.278 other helpful SDN tools I just mean finally this is my last slide. Um this takes S flow 00:37:27.278-->00:37:32.417 information from the network and writes it to a Mininet topology and then communicates those 00:37:32.417-->00:37:37.155 flows to the controller. So basically you can translate any network into an SDN, even a lab 00:37:37.155-->00:37:42.060 network, even a- wh- whatever you want at home uh that you wanna test this out. I- I was 00:37:42.060-->00:37:46.698 trying to find out good ways to migrate to SDN and there's not a lo- not any good opensource ways 00:37:46.698-->00:37:50.835 of migrating from a traditional network to an SDN and so that's where this is supposed to come 00:37:50.835-->00:37:55.607 in handy. Um this will actually take you jus- take your regular Sflow netflow information you're 00:37:55.607-->00:37:59.944 sending from your switches point it at uh at this little application, and it will start 00:37:59.944-->00:38:05.450 building Mininet topologies based on on that and sending those flows to a controller and 00:38:05.450-->00:38:09.687 those flows by the way don't have to be sent to a Mininet, they can definitely be pointed 00:38:09.687-->00:38:13.224 at a regular controller and you can actually migrate- please don't do this in production and 00:38:13.224-->00:38:18.229 then call me and like [laughter] in theory you can migrate a production network with this 00:38:20.298-->00:38:26.070 tool uh I wouldn't recommend it but uh but check it out uh- eh- my issue is I was trying to 00:38:26.070-->00:38:30.241 think of a creative name for it, so it- it takes Sflow information, writes it to a 00:38:30.241-->00:38:33.778 Mininet topology, FloWrita, it it just made sense [laughter] [applause] so anyway, uh that's 00:38:33.778-->00:38:38.783 all I got folks, are there any questions before- before I get booed off the stage here? 00:38:45.423-->00:38:50.728 [applause] Any questions? Wonderful. Well thank you so much I appreciate it, I'll be 00:38:50.728-->00:38:55.733 around here afterwards I'd love to- I'd love to talk, thank you [applause]