 This is December 2018 only a few days after Christmas and lots of people probably got some fancy new Internet of thing device that may or may not be secure. So maybe you don't want it on your network But I wanted to talk about that a little bit So there's always a lot of questions of do I or do I put on a network? What should I have on my network or what should go on some type of separate segregated network? so these devices that If they get attacked or if the refrigerator gets compromised it doesn't become an attack vector for your other devices I just want to do this quick video to talk about How you can separate them on a network? Why you should or shouldn't and things you can do to make them still function despite them being on a separate network So I drew a diagram what we've done here is This is essentially Kind of a microcosm of a piece of our network broken out here So you can see how the devices are set up So the orange here is the 192 1683 network where I have the unify switch My computer several other computers phones and things like that. This is more or less the trusted network per se Then we have the 172 network here that has internet only So we can only get out to the internet cannot go out and look at local network And then we have the avahi avahi protocol. I've done a video on this before I get the naming possibly wrong in MD and s because some people have Messes me with concerns when I did that video thing, but doesn't that break the security model? No, and that's what we're gonna kind of talk about real quick here so the reason with IoT devices you may want them on a separate network is if they become compromised they become attack factors and When someone gets in your network and anything that reaches out through the firewall and listens for commands Which is how most IoT devices work when they're listening for commands And if they were insecure or poorly designed and someone finds a way to hijack the commands coming into them And we've seen many devices by lots of random companies come out there get to market But not really have any security auditing done until they were deployed in a market Which is what's created many of these out botnets these devices once hijacks They start looking for other things to hijack now many of them simply go back out to the internet to you know Go back to attacking things or whatever their purpose that they were set forth to do becomes But you don't want that to be you or something local on your network now in theory if your computer's patched It should be safe from said things But you still don't really want them making noise on your network So we put them on a separate network now. I have a couple devices listed here like the Chromecast or the Amazon dot Either one of those are Statistically less likely to be attack vectors because both Google and Amazon have a pretty good security reputation But lots of people get those off-brand Random tablets and things like that or random friends coming over with their phones that maybe they Siloed it something and maybe has a security compromise on it that you don't know about and it's looking for things to start talking to Or as I have a screenshot from our friends over at Silicon Valley the wonderful the refrigerators that for some reason need to be connected to the internet and You know, maybe the company's really good designing refrigerators But maybe not so good at designing security related to those refrigerators and your refrigerator becomes in a Potential attack point and you don't want it wandering around so The reason I mentioned evi protocol is some of these devices require talking to your local devices to get them to function fully and Chromecast specifically is one of them that I believe some of the Apple Airplay stuff does and I think so knows and a handful of other devices They use this protocol referred to as MD and s and by loading up the evi protocol in him maintains the MD and s look up Now first let's talk about how the rule sets work here again Anything on the dot three network here full access to the internet and Has access to these devices and it sometimes causes confusion by allowing the three network to talk to the 172 network That means you requested from your side of the network and specifically 3.9 is the IP address of my computer If I go in and make a request to a device on this side I'm the one to initiate the request and will only send back data based on my request for data But these on this side here cannot initiate a crest or even have awareness of The 192 network so anything on a 172 network if it scans its local network It may find the other things on this IOT network But it doesn't have any ability to reach out to any other private addresses in the 192 space Because we have them block and we'll get into the rules real quick How I have them set up in a second now. This is also where we need the evi DNS because the Chromecast wants to talk to the phone and if the phone is on a separate network It doesn't see it now what MD and s is is a protocol that allows DNS lookups Specific type of DNS lookups you can look up the RFC spec and just Google MD and s and read into the details of it That doesn't break the security model because it's only publishing lists Now this list then gets maintained on both sides of the network the things on this network and do a call Give me the MD and s list of devices that support these protocols The MD and s list has it and the Chromecast will be listed in there and evi running maintains that list So you are still doing from a security model an initiated connection from here to talk to here Where the initiation is starting on the 192 network and then requesting something over on the 172 network In the case of Chromecast you would be opening up Maybe the YouTube app you select the Chromecast app and you say hey YouTube will then speak to that device and tell it go get this YouTube video and display it on that Chromecast So this is where the confusion came in because some people think well if it publishes the IP addresses of these things Doesn't that break the security? Well, no the firewall rules maintain the separation between these devices and with MD and s It's not really talking back to the phone. It it's just giving it the feedback the phone requested via that app So it's not giving even with the initiated connection some type of massive back access to it now If somehow you had a device that was MD and s and an app that controlled it You could potentially have an issue if there was some exploit both in the app the methodology And if it requested something was able to send something back It's a real edge case and if you're that worried about security You wouldn't have any of these devices on your networking You wouldn't be trying to use Chromecast or any of those devices now the other thing that would go on this network Let's say would be things like garage door openers and other random IoT light switches and stuff like that But most of those don't even need any type of MD and s look because they don't look locally for the network The methodology that they connect with is they contact wherever their host server is as a service For example, I've seen a few garage door companies that use an Amazon EC2 cloud instance They contact that so you get them you set them up You go to their portal whatever that portal may be and it talks to that portal in the Amazon cloud Then what your phone does when you load it up the app for that garage door opener It talks to the Amazon portal and because the two devices don't ever have to be on the same network There's nothing you really need to do on here You can have them on a separate network and have these same rules and it doesn't break anything at all This is actually how many many cloud devices work. They don't want to deal with trying to figure out local IP addresses and things like that The ones that do are gonna use probably MD and s So there's never really any port mapping that needs to occur between these Unless you try to get complicated and put a printer over here You'd have to map the ports that a printer between the firewall and the local network to get it on here I'd usually recommend people not do that Because it creates you can be done But you're gonna create a more complicated network for yourself because there's a lot of things that need to go on back and forth with Them because they kind of expect to be on the same network, especially with wireless printers But once again our wireless printers a threat model. Yeah, unfortunately found some security flaws in them I generally recommend commercial printers like directly plugged in because they're gonna be better Take that for what it's worth that is just kind of a risk of having the printers in there If the printer goes out and wants to talk to the cloud some wireless printers are simpler And I don't know every model of them that you can just keep them on your local network And they don't need to call out or you can just plug them in USB and mitigate the potential for some of those issues All right, let's actually dig into the rules of what this looks like Now the first thing I want to show you is the AV H. I Dam by Damon and it's really simple and able to buy Land and IOT for the sake of this discussion That's how we're going to be doing this. Don't worry about the other networks We have several other things for other purposes But I want devices on land to be able to talk to via MD and S devices on IOT Check a few boxes here pretty straightforward no advanced settings in here hit save And that's what bridges that MD and S across those devices. Once again, you're not changing any firewall rules You're not allowing the passing of any traffic It's basically like publishing a DNS list and listening on both sides with the DNS to make a list But no actual traffic is going back and forth related to this It's just a listing service that list DNS entries next Private networks versus public networks. I labeled this called LTS private networks LTS underscore Private underscore networks description our private network list type networks And you find this under aliases in the firewall the nice thing about aliases because I have Three different networks. I don't want anything on the IOT network to be able to come back and talk to it all and They're cleverly named out three dot two and VPN. There's the networks right here So let's talk about the rule now So we've created this little alias now if you only have two networks You could forgo this and only type in the IP address as a destination like this and we're gonna show you both ways to write this rule So here's what the rule looks like one rule that says source Is IOT net so source is the IOT network the 172 network we talked about and From that source network, where are we allowed to go? What's the destination? So if you were to add the rule as Wide open asterisk is basically wide open. It would be able to go anywhere else on the network You have to have at least one rule in here to allow the traffic to route We're saying not wide open. So Any thing in the IP for IPv4 protocol space source IOT network port Asterix any port Destination if you notice a little exclamation point ahead of this and we mouse over it We see our alias. It's saying hey exclamation point not these and I just refer to the rule in my description Allow all except which means allow all networks except this one. I'm gonna go over here now And show you how that works Single-host or alias LTS private networks invert match Simple the invert is really important because if we didn't invert this it would do exactly the opposite We want it wouldn't allow it on the internet It would allow it to my private networks and we definitely don't want it there now if you didn't want to write the alias You could put 192 168 plus zero single-host or alias. I believe There we go. You have to choose network if you want it to be a network destination So three does zero such 24 if I only wanted to block the one network, but like I said, I prefer to do this as an alias So we're gonna say single-host or alias Delete I Just type the first letter LTS here's our description allow all and that's it for the rules hit save and now the IOT devices Can't get back to me, but I can get to them and quick demo to show you how that works All right now that we've seen the rules. I have Debian server sitting at the 172 1669 address last 24 and my computer is 192 168 3.9 as shown here and I'm SSH den and what this is is pftop And we filtered for host one seven two sixteen sixty nine thirty nine So you want to see what this hosts and see and show you how the rules work in action So if I request an ICMP packet from 172 16 69 39 We now see three dot nine Getting data over to here Graphic type is ICMP as you can see right here So no problem now and this is like I said the part I want to make sure people are clear on So if we try to ping 192 and 683 dot nine Nothing dead air the firewall will not allow an established connection from there So this is that little part of confusion that I just wanted to make sure cleared up with people When you're getting into networking they assume if the connections made one way that Automatically means something to be back. So the firewall prevents based on the rules a connection from coming back So I can still ping this but that still doesn't allow it because my computer didn't request data So here's that ICMP rule. It's going to expire. Here's the one up here No data traverses because of the firewall rule, but to the top here If we ping news comm I Can ping out I can get out to the internet and you can follow what happened here We have an ICMP packet We have a UDP packet because it had to do a lookup port 53 to figure out the name of the Address I wanted to ping and now it's sending data So it has access to the internet, but it doesn't have access to the local network So, you know, these are the simple rules that you put it on there It doesn't have to be that complicated that one rule with an invert in there saying don't go to my private network Just go out to the internet and do your IOT thing and hopefully you don't get attacked And hopefully you don't get compromised and away you go now This also expands it so later you decide to do things like rate limit or speed limit that particular Leg of the network you could do that You could put in a rule that says my IOT network can never have much bandwidth because you don't want it to take away That's also a good way to do this. So you don't take away from your main network bandwidth. That's not a concept You can do that's not hard to do when you apply some of the rules But just in general it they're usually not bandwidth hogs and well except for things They Chromecast that by their nature if you're watching Netflix at 4k gonna use some bandwidth But this allows you to have them on a separate network where you can worry about them a little bit less But you can still get to them to make things function like the Chromecast using the avi protocol for your MDNS So hopefully this concept makes sense to you And it's just like I said a real basic overview And if you want to know in-depth more walk through step-by-step my getting started with PF sense video Which I'll throw a link to that will get you started from loading it to creating these network rules step-by-step all the way through I've also got several ones on Unify of how to line up VLANs with PF sense. It's pretty straightforward to do And always hopefully this was helpful or enlightening to get you a little bit better understanding of what the risk might be for having an IoT stuff and Why you might want to just keep it on another network and how simple it is to do that and still maintain functionality Not too big of a deal. Alright, thanks Thanks for watching if you enjoyed this video Go ahead and hit the thumbs up if you want to see more content for my channel Go ahead and hit subscribe and the bell icon and hopefully YouTube will send you a notice If you're interested in contracting launch systems for any type of IT services work or consulting work Go ahead and head over to Lawrence systems comm and fill out our contact and get in touch with us If you would like to help the channel out in other ways You can use our affiliate links below in the description or we have a link directly to our launch systems page We have a list of different affiliate offers And it's very appreciated if you use any of those for signing up any of the services and many of them Offer you discounts if you want to head over to our forums There'll be a link in a description for our forums Wherever they may be because we've been looking at different forum platforms, but they'll always be relevantly linked right there All right Once again, thanks leave some feedback and comments below on this video if you loved it if you hated it I try to reply to everyone the people who hate and the people who love them So thank you very much and see you next time