Part 2 | Ultimate Home Network 2021 | VLANs, Firewall Rules, and WiFi Networks for IoT UniFi 6.0

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
Today on the hook up it’s time for part 2 of my Ultimate Secure Smart Home Network series. In Part 1 I walked you through hardware selection using UniFi equipment and in today’s video I’m going to show you how to get your network setup using cybersecurity best practices including VLANs, Wireless networks, and Firewall Rules as well as explaining all of the advanced options in the UniFi 6.0 controller. In part 3 I’ll finish it up with Wireless signal optimization, Port Security, Intrusion Prevention, and VPNs. This turned out to be the longest video I’ve ever made, watch the whole thing and I guarantee you’ll learn something new, but I’ve also got timestamps and chapter markers if you’re interested in a specific topic. Before we get started, I think it is important to mention that convenience and security are opposing ideals, whether you’re talking about physical security or cyber security, the outcome is the same: Most increases in security will also come with a decrease in convenience. Leaving your doors unlocked saves you time and effort when coming home, but at the cost of your home’s security and your personal peace of mind, and the same goes for your network. The goal is always to minimize this tradeoff using technology but whether it’s increased setup time, decreased network speed, or even loss of some functionality, you’ll need to decide where you want your network to fall on the continuum of convenience vs security. I’m going to show you my setup, which I would put closer to the secure side than the convenient side, but you can pick and choose the parts that you think are important if my setup too conservative for you. This video is sponsored by Zemismart and their new no assembly motorized curtain system. The adjustable motorized curtain rod can accomodate window openings from 62 inches to 157 inches and can be installed in minutes by sliding the adjustable tracks to your desired size and plugging it in to a nearby outlet. The curtains connects via WiFi to the Tuya smart life app giving you amazon echo and google home control, as well as allowing you to easily integrate them into your smart home hub. Check out the assembly free motorized curtain rod from Zemismart using the links in the description. In the internet of things device communication can be complicated, but for the most part IoT devices can be divided into four main categories: Devices that need to communicate with a cloud service outside of your network, devices that only communicate inside your local network, devices that need to talk to a cloud service and devices on your local network, and last, devices that don’t need outbound communication at all, and should only speak when spoken to. For example: My sense energy monitor collects data about my electrical usage and sends that data to the cloud. When I open up the app on my phone, I’m not actually talking to the device in my house, I’m communicating with the cloud as a middle man. Similarly, when I use that energy data in my home automation platform, the energy monitor doesn’t talk to the hub, despite being 20 feet away from each other, they instead use the cloud as an intermediate. This means that the sense falls into the IoT device class that should be allowed to communicate with the internet, but blocked from all local communication. My Amazon echo devices are similar in that they are communicating with the amazon cloud for 99% of what they do, but they do need to talk to each other on the network in order to synchronize multi room audio, and they need to talk to my home assistant server to process alexa local devices in node-red. So even though they are in the IoT device class, I’ll also need to set up a custom rule to allow them to communicate with one another. As a general rule of thumb, I try to avoid cloud devices and choose local control whenever possible, but anything that utilizes a service, be it Netflix, Disney plus, or even just the amazon cloud unfortunately can’t operate 100% locally. That brings me to the next device class, which is for all the locally controlled devices on my network. This includes all of my smart switches that run the custom Tasmota firmware or use shelly’s local control options. These devices don’t need any internet access and only need to communicate with my home automation server. I call these devices my network of things, or NoT because they only need local communication. Similar to the IoT network, they don’t really need to communicate with each other either, so I can block all of their traffic except for communication over specific ports with my home automation server. If you’re not sure whether a device should be on your IoT or NoT, unplug your internet connection and see if it still works, if it does, it’s NoT, if not, it’s IoT. Next are devices that should be able to access everything on the network. Cybersecurity best practice actually says that this device class shouldn’t exist and that if a device needs this kind of access it should be temporarily elevated to higher privileges to complete a task and then returned to a lower privilege state. However, in an effort to maximize convenience I keep all of my family’s phones, computers, and tablets on this main untagged VLAN, but a little later we’ll talk about how security features like intrusion prevention systems may help mitigate possible vulnerabilities on these devices. Another questionable decision that I’ve made on my network for practical reasons is to put all of my completely untrusted devices onto my main untagged VLAN. Here I’m specifically talking about security cameras, which are ironically one of the most insecure devices from a cybersecurity standpoint. The way that a security cameras work is that each one has a little video server running on the camera itself and if a device like an NVR wants to view that feed it contacts the camera and initiates the stream. There’s no reason for a device outside my network to initiate a camera stream, and no reason for a camera itself to initiate a connection with another device so I can block 100% of their outbound traffic via firewall rules without affecting their functionality. The reason for putting them on the same untagged VLAN as my server is that it reduces the strain on the router to not have to pass 11, 5 to 8 megapixal video streams across VLANs from each camera to the NVR. Just having them on the untagged VLAN doesn’t represent a security flaw since they will have a corresponding firewall rule, the real problem is that this represents poor network port security. An easy way to get full unlimited access to my network would be to tear one of my security cameras off the wall, unplug the ethernet cable and plug it in to YOUR device. Because the security camera group is defined by their IP addresses, which are ultimately assigned based on their MAC address, a new device will pull a fresh IP address and therefore will not be bound by the camera firewall rule. Thankfully, there’s more than one way to secure a network, so we will deal with this issue using port restrictions later on. Now that we’ve talked through the theory behind the network architecture, let’s see how to actually implement these policies in the new UniFi 6.0 controller interface and dashboard. The first thing I did on my UniFi Dream Machine Pro was set up a local admin account and disable cloud access. To do this click on users from the UDM local portal, then either make yourself a new super admin local user, or add local credentials to your cloud account. If you want you can also completely disable cloud access to your UniFi controller by going to settings, then advanced, and toggle the “Remote Access” switch to off. It’s unfortunately still not possible to do initial activation and setup of UDM Pro without a ubiquiti account, but at least you can move back to local control once it’s installed. There is currently a significant amount of customer backlash from this issue and pushing the same limitations to the cloud key gen2, so hopefully things will change in the near future. After you’ve logged in with your new local credentials, click the network button and if you’re on Controller version 6.0 your dashboard will look something like this. If not, you can go to settings, user interface, and then toggle the new dashboard and new settings switches. You can try out new clients as well, but I personally don’t like it because it’s missing important information like which access point each device is connected to. For the time being you can also easily toggle between new and old settings if you can’t find the setting you need in the new menus. The first thing that we need to setup are the networks, and we are going to start with those 3 different virtual networks within our single physical network. To set these up go to networks and click on add new network. My first network will be my IoT network, and after adding the name you’ll see that all the other important settings are now in the advanced tab. My IoT network is going to be assigned to VLAN 20 and isn’t associated with a domain name. The next option on the list is for device isolation, which sounds great and like exactly what we want for the IoT network, however, I’m not going to use it, because even though this likely turns on some internal firewall rule, that firewall rule doesn’t show up in the interface anywhere, so it’s impossible to allow exceptions properly since we don’t know whether that rule is being applied at the beginning or end of the chain. The next option is IGMP snooping, which is a feature that specifically applies to multicast communications. To understand the difference between the different types of network traffic lets use twitter as a model. On twitter you can send private message to a single other twitter user and they can respond on that direct channel, in networking we would call this unicast. Another way that you can interact with people is you can follow them, and then they can send out tweets that will go to all of their followers, they aren’t necessarily talking directly to you, but you’ve indicated that you may be interested in what they are talking about. In networking this is called multicast, and IGMP is the protocol that is used to figure out who is following who, so that when a computer sends out a multicast message it gets delivered to only the interested parties. There’s also another type of communication called broadcast that’s more like the announcements that Twitter makes that you don’t have any option but to look at, broadcast is a complicated topic, so for now let’s focus on Multicast. As I said, IGMP is the method that your devices use to indicate that they want to receive another device’s multicasts, the problem is that by design multicast only works within the same network, and since we have 3 separate virtual networks, the devices on one VLAN have no way to follow the devices on another VLAN. However, if we enable IGMP snooping the router looks at the type of traffic each device is interested in, and then sends the same type of traffic from other VLANs in addition to the local VLAN traffic. HOWEVER, there is a problem, if the VLAN you are assigned to doesn’t have any of the multicast traffic you are interested in, the router will never know that you want to see it. This is getting confusing, let me give you an example: All of my chromecast devices are on my IoT network, they need to be able to talk to the internet to stream all their services, but I also want to be able to cast from my PC to the chromecast. When I click the cast button on my computer it will generate a list of available devices based on multicast messages that the chromecast sends out basically saying “Hey, I’m an available casting target”. If I put a chromecast device on the same VLAN as my computer, then my computer would join that IGMP group and would hear messages from all the chromecasts on all the VLANS, but since there are no chromecasts on the same network then my computer never joined the group and IGMP snooping doesn’t know to send those messages from the IoT VLAN to my computer. That was a REALLY long winded way of saying that if you have devices on your network that advertise their services like casting, over the air updates, voice assistant integration and lots more you may need to turn IGMP snooping off, as well as turning on the MDNS repeater, which you do by clicking on settings, advanced features, advanced gateway settings, multicast DNS. Next you’ll set up the subnet for your VLAN. I like to keep my subnet the same as my VLAN number, meaning if I put in VLAN 20, I’ll want my gateway and subnet to be 192.168.20.1/24. The /24 part at the end refers to how much of the IP address will be the same for the entire subnet, 24 means the first 24 bits are part of the address and the last 8 bits will vary based on the device, another way you’ve probably seen this is in the subnet mask, which in this case would be 255.255.255.0, meaning the first 3 8 bit numbers are part of the network address, and the last 8 bit number is part of the client address. UniFi is doing their best to make sure their users don’t need to understand all this stuff, so they give you the option to auto calculate your subnet. They also give you the option to auto scale the size of your network as needed, which I think is really strange, and I can’t think of any reason you’d want to do this, but as far as the DHCP range is concerned there are some reasons you don’t want all 254 addresses in your DHCP range. IP addresses need to be unique for each device on your network, and they can be assigned in a few different ways. The most common way is for a device to request an IP from your router called, which is called DHCP, and in this case your router looks at the IP addresses currently being used and assigns a free IP address from a range that you define. The second way is called a DHCP reservation, in which you tell your DHCP server, the dream machine pro in this case, that you always want to give a specific IP address to a specific device based on its MAC address. Every time that device attempts to connect to your network it will ask for an IP address like normal DHCP, but the dream machine will always give it the same address and will never give that address to another device. The third and final way is called a static IP address where the device itself to defines its own IP address, and it TELLS the router what its address is instead of asking. Static IPs can lead to issues if they are outside of your defined subnet, or if that address is already taken by another device. A common way to avoid these IP conflicts is to start your DHCP range above 100, this will give you roughly 153 DHCP IP addresses and 94 static IP addresses. However, almost all of my devices will use DHCP, so I prefer to keep the DHCP range large and then reserve IP addresses in the router for any device that I want to use the same IP address every time it joins the network. Again, long story short, just define your own network size and DHCP range rather than having the controller automatically expand your network. The rest of the options will be specific to your setup. I personally specify the DNS servers that I like my devices to use so it doesn’t default to my service provider’s DNS server. I used cloudflare’s dns at 1.1.1.1 as my primary server and google’s dns at 8.8.8.8 as my secondary. I also define my own network time protocol server since I run the Chrony addon on my home assistant server, this helps me keep NTP requests local so I can block more outbound traffic in my firewall. This does come with some inconveniences, namely that some devices don’t pay attention to the NTP server specified to them by the router, in which case you’ll need to log into those devices to change their NTP server manually. After you’ve changed any extra settings for your specific network, go ahead and hit save and repeat that same process for your NoT network, except this time you’ll specify the VLAN as 30, and the gateway and subnet as 192.168.30.1/24. Remember if you want ALL of the multicast data from this network to be repeated on your other VLANs then you should disable IGMP snooping on this network. Last, you’ll may want or need to change your default LAN network to use a different subnet if you already have a bunch of devices setup using that IP address. To do this just click the pencil icon to edit, and then edit the gateway and subnet addresses as needed. UniFi has also added the ability to designate a network as a work or family network. These networks work similarly to any other network type, but will use a special domain name server or DNS. For the uninitiated, DNS is how your computer finds out the IP address of a remote server given its domain name. In these special family and work networks the dream machine uses its own forwarding DNS server which sends all adult sites into something called a DNS black hole, which basically just makes the site show up as unresponsive. Additionally, the dream machine’s DNS can also redirect google and youtube traffic to their safe mode subdomain in order to filter explicit material and turn off comments. This isn’t new tech, and has been relatively easy to implement in the past using popular software called piHole, but it’s a neat addition assuming they do a good job upkeeping the list of prohibited sites, which I don’t have high hopes for since the list of sites that they use for deep packet inspection hasn’t been updated in at least 10 years now. Since I have an 8 year old I decided to give this a shot, so I set up a 4th network called family, and I’ll show you how to force specific wired devices onto that network later on, but unfortunately using this implementation, the only way to get wireless devices onto this content controlled network is to define a specific wireless network for it. Now that we’ve got our networks defined we need to assign them to wireless networks. The way that I’ve divided my network I know that my IoT and NoT devices are stationary and should be connecting to a specific access point on a specific frequency band. For this reason I’ve broken out my SSIDs not only into IoT and NoT, but also the area where the devices are located, downstairs, upstairs, or outside. In the old UniFi controller I accomplished this with SSID overrides on each access point, but that feature has gone away and the new method is to use WiFi groups. To make these groups you need to start configuring a wireless network, so in settings click wifi, then add wifi network and then click on advanced. Each wifi group needs to have at least one access point associated with it, but can include as many as you want. I’ll make a group for upstairs, downstairs and outside that contain only a single access point, and then there is also a group that contains all the access points for my roaming devices. For each wireless network I will use the same base name, in this case TaitIoT or TaitNoT, and then an underscore followed by the location of that device. For instance my outside NoT network is called TaitNoT_Outside and I’ll assign it specifically to the NoT network and the outside access point group. It’s also helpful to disable any unused radios for these networks, for instance, I know that my outside NoT group only contains 2.4 gigahertz devices, so there’s no reason to broadcast this SSID on the 5 gigahertz channel. Disabling unused SSIDs will help reduce interference and decrease the number of beacon messages being sent out by each access point. Next are the advanced features. If I have one main gripe with UniFi it’s that a lot of their options are vague and require a decent amount of digging just to figure out what they actually do, end even then there is sometimes no official documentation. A general rule of thumb for any advanced feature is to turn it on and see if any of your devices respond negatively, and if they do, turn it back off. That being said, here are some basic explanations of what these features do: Unscheduled Automatic Power Save Delivery allows devices to tell the access point that they want to save battery, and any data meant for a device in power saving mode will be stored up for a short period of time and then delivered all at once, instead of a having a constant stream of data to the device. This allows the device to turn off its WiFi radio for a longer period of time without missing information or being disconnected from the network. In theory you should be able to enable this feature without any issue, but your specific device will need to support UAPSD to see any benefits, and as I said, if you enable it and you see issues in older devices you can safely turn it off. Next is multicast enhancement, the first of the cryptic options. From what I can tell this is just a place to enable IGMPv3, which is how devices join multicast groups as we discussed before. I have multicast enhancement enabled on all of my networks and I’ve never had an issue with it. It is oddly disabled by default. Forcing high performance devices onto the 5ghz network only means that if a device supports 5 gigahertz it only gets to use 5 gigahertz, even if the 2.4 gigahertz signal is stronger, which is a bad plan because of attenuation issues with the 5 gigahertz band. I’d say the only reason to use this is if you have an open air office with lots of cubicles where every device will have direct line of sight to the access point. Keep it off for home use. BSS transition monitors the signal strength of your devices and sends a special management frame to weak signaled devices telling them they may want to transition to a different access point. This feature should be disabled on all of the networks that are using a single access point, since even a weak signal device shouldn’t try to roam to a different access point. I do have this feature enabled for my main WiFi network that I use for phones and tablets. Proxy ARP should be off for 99% of networks, and if you need to turn it on then you already know what it means. Layer 2 isolation means that the access point doesn’t even check firewall rules before denying communication between devices on the same network. This is useful on a guest network, but should be off on all your other networks. Legacy support will allow really old devices that use 802.11b to connect to your network. Remember that adding these older slower devices will increase the time that all of your devices will need to wait to talk to your access point, which will not only slow them down, but may also cause connectivity issues. Unless you have a specific very old device that you can’t live without keep legacy support off. Last is enable fast roaming, and similarly to the BSS transition frames you want to keep this setting off for all of your networks except for the main roaming network. On my main network I only have laptops, phones and tablets which can all use fast roaming, but if you notice connectivity issues when changing locations in your house you should shut this feature off. Under security you should have WPA-2 default, hide SSID off, and PMFs on either optional or disabled. PMFs or protected management frames mean that only authenticated devices can send frames that instruct clients to associate, disconnect, or roam. It seems crazy, but the way that WiFi was originally designed, any device can tell another device to disconnect from the network, even without knowing the wifi password. This leads to one of the most common attacks on wifi networks called a deauth attack where a single device sounds out thousands of deauthorization management frames to disconnect every device in range. This attack is a common first step to a man in the middle attack called an evil twin, a method for collecting authorization frames to analyze for a network attack, or just as a plain old denial of service. Protected management frames are great, and they will help to provide much more secure connections in the future, but as of right now there are not enough devices that support them to be able to set this feature to required, and I’ve even had some trouble with my ESP8266 based devices when it is set to optional. Keep your group rekey interval set to the default. This section also allows you to allow or deny devices based on their MAC address. I had an Amazon Echo Show that I temporarily switched onto my main network to record part of a video and even after switching it back to my IoT network it would occasionally show up on my main TaitWiFi network, even though I told it to forget that network. To prevent this I added its MAC address to the deny list for my main network preventing it from joining ever again. The last section allows you to turn off your WiFi network based on a specific time of day. I don’t find this useful for my setup, especially since UniFi integration for home assistant lets you shut off internet access for specific devices, so I don’t specify a schedule in this section, but if you had a specific kids network you could turn off the WiFi to that network at a certain time. Here’s a quick reference for setting up your WiFi network options, remember you’ll need to create a separate network for each VLAN and access point if you want to force devices onto a specific access point based on their location. Each access point can only broadcast 4 different SSIDs, so with a main, IoT, NoT and guest you will be maxed out. The next step is the most important one for the security of your network. Firewall rules or what are sometimes called Access Control Lists or ACLs are the main system that governs whether devices should be able to communicate with each other or the outside world. Best practice in network security is a concept called Zero trust, or similarly least privilege, which basically means that you should start by blocking all traffic to every device on your network, and then only grant specific access to devices that need it, when they need it. In the UniFi controller, firewall rules are processed from the top down. That means that if traffic is specifically allowed by a rule at the top of the list, no other rules will be checked to see if they apply. Because of this I find it easiest to put specific allow rules at the top of the list, and generic deny rules at the bottom. If you’re using a firewall other than UniFi make sure yours operates the same way before blindly following this tutorial, otherwise you could lock yourself out of your network completely using too broad of deny rules. Speaking of other firewalls, another issue when dealing with multiple vendors is knowing the built in implicit rules. UniFi uses implicit allow for all local networks, and implicit deny for your external connection. This means that if you don’t make a firewall rule specifically denying it, all local traffic will be allowed between VLANs on your local network and similarly, if you don’t make a specific allow rule, all incoming traffic from external sources will be blocked. Different vendors will have different built in policies, like using implicit deny between VLANs, but UniFi allows all VLAN to VLAN traffic by default. You can view these built in rules in the firewall section where they show up as ghosted text and cannot be edited. On my network I use home assistant, plex media server, amazon echoes with multi room audio, chromecasts, and rokus. I’ll setup my rules based on these devices. If you use other services like Sonos for instance, you’ll need to figure out which ports they need. If you use a service that isn’t covered in this video and figure out a firewall rule to make it work please post it as a comment down below and I will not only check it for security flaws, but I’ll favorite it so other people can use that rule if they need it. Okay allow rules first. The first firewall rule that we need to make is called allow established and related. This means that if device A has permission to talk to device B, then device B will be allowed to answer, even if device B isn’t allowed to initiate the conversation on its own. Lots of people commented on my last video that established and related is built in to the UniFi firewall, but as you can see it only exists in the Internet In and internet local areas, so it doesn’t apply to LAN traffic. To make a LAN based established and related rule click on create new rule, select LAN in, call it allow established and related, apply before other rules, and accept any protocol, then down at the bottom under advanced you’ll activate match state established, and match state related, then hit apply. A surefire way to cause issues with any device is to block it from getting the correct time. Using incorrect time can make it impossible to use encryption properly, and may cause some devices to stop working entirely. For this reason I let all of my devices have access to the network time protocol or NTP which communicates on port 123. This is an outbound communication and the response is covered by the built in “allow established and related” rule. Click on new rule, then select LAN in, Next give it a descriptive name, I’ll call mine “Allow All Local to NTP” We want this rule to be applied before all other rules, and we want it to accept the traffic that meets this criteria. Remember, these are accept rules, so you should make them as specific as possible. I happen to know that the network time protocol uses UDP, so I’ll specifically only allow UDP packets. Under source type I want to use a group of IP addresses, so I’ll select address/port group and then in the IP group I’ll select “Create new group” and I’ll make a group called “All Local Addresses” which contains all of the IP addresses inside of my network, which are 192.168.86.0/24, 192.168.30.0/24, 192.168.2.0/24 and 192.168.20.0/24, after entering all the IP addresses hit create new group and make sure it’s selected in the dropdown. This traffic will be allowed to originate from any port, but should have a destination port of 123. You can define this single port using the IP Address dropdown option, but I like to make groups for everything so they are more descriptive. Click create new group, then name it NTP port and put in port 123. The next rule to configure will allow my IoT devices to communicate with my home assistant server. Depending on the type of devices you have on your network, you might not need this rule at all. This rule is obviously only necessary if you’re using a home automation server, and only if the device is listed as local push. If they are listed as local polling then home assistant only needs to be able to communicate with them, which it can by default because it’s on the main untagged VLAN that we are giving unlimited network access to. If your device is listed as cloud polling or cloud push then the local devices do not need access to home assistant since they will use the cloud as an intermediate. The broadest setup of this rule should be LAN in, applied before, accepting all, from source network IoT to destination home assistant server. I only have one home assistant server, but again, I like to make a group with just that one IP address so the firewall rule is more descriptive. To follow the concept of least privilege you can make a group of IP addresses that need local push access and instead using the entire IoT network as the source you can use that local push group. The fewer permissions that you give the more secure your network will be. Remember that any time you add a device to one of these IP address based groups you should also reserve that IP for only that device using the UniFi dashboard, this not only ensures that your device will take the same IP address each time it connects to the network, but it will also prevent another device from getting that IP address, and therefore having more permissions than it should. My next rule is to allow my NoT network to communicate with home assistant. In my previous video I limited this rule to only MQTT traffic, but with all of the new integrations and protocols used by home assistant for things like Shelly discovery and WLED I’m recommending just giving the NoT network full access to home assistant on any port rather than only the MQTT ports. For this rule, you should choose LAN in, apply before, allow all protocols, and for the source it should be the NoT network, and destination should be your home assistant server, port group any. If this rule is too broad for you could define a more specific group of devices within your NoT, but for me, all of my NoT devices are communicating with home assistant in some way, so this makes sense. My amazon echo devices are on the IoT network, which means they can’t communicate with any devices locally. I’ve found that for multiroom audio to work correctly the echo devices need to be able to communicate with each other, so I’ll make a specific firewall rule called echo to echo, in the LAN in area, apply before other rules, allow all protocols, with a source of my group of Echo devices and a destination of my group of Echo devices. Chromecast devices need some specific ports open for communication, so I’ll add a rule called allow chromecasts, which will be in LAN in, will apply before other rules and will allow all protocols with a source of the IP address based group of chromecast devices and a destination of any device on the network that I may want to be able to cast from on these 7 chromecast specific ports. On my network my casting devices happen to be all the devices on the main untagged VLAN but if you want to limit which devices can cast, you can make a smaller IP address based group for that. Also a quick note, I’ve noticed that chromecast streaming functionality is significantly increased by disabling IGMP snooping on the IoT VLAN like we discussed earlier. My last allow rule is to give my streaming media devices access to my Plex server. For this rule I’ll choose LAN in, apply before, allow TCP and UDP with a source of an IP address based group called streaming media devices, and a destination of my plex server, specifically on these 10 ports required for plex and it’s different services. At this point, my firewall is exactly the same as when I started since all I’ve done is make allow rules, and the UniFi LAN firewall uses implicit allow, meaning all traffic was allowed anyways. So to secure my network I’m now going to make broad deny rules for each network. My IoT devices shouldn’t be able to communicate with any devices on my network, so since I already created a group called all local addresses I can make a new rule called Drop IoT from local, choose LAN in, apply AFTER other rules, drop all traffic with a source of my IoT network and a destination of my all local IP addresses group that I made earlier. If I ever want to add an additional VLAN I just need to remember to add it to this group. My NoT Devices shouldn’t be able to communicate with any devices at all other than the MQTT allow rule that I specified before so I’ll make a rule called drop all NoT, choose LAN in, apply after and deny all traffic with a source of my NoT network and a destination of any IP address and any port. And last I’ll make a similar deny all rule for my security camera group. Lan In, apply after, drop all traffic with source IP address based security camera group, where I’ve reserved their addresses via DHCP, and destination of any IP address and any port. As I said before, firewall rules are read from the top down and it’s a kind sudden death scenario where the first time a packet matches the conditions of a rule then that rule is applied and no other rules are checked. So each time a packet comes through it will check to see if it is in any of the allow specific allow rules, and if not it will be denied by the generic deny rules. There is a theoretical speed increase to be had by putting the rules that apply to your most common types of traffic higher up in the list, but in practice on a home network there is no reason to stress about which allow rules are first, as long as the allows come before the denies. Even though firewall rules are the most important tools for securing your network, there are other features available in the dream machine pro that provide additional layers of security. In part 3 of this series I’ll cover intrusion prevention systems, port security, and setting up your own virtual private network to avoid exposing services on your network to the internet. If you learned something today, make sure to hit that thumbs up button so youtube knows it’s a good video. Thank you to all of my awesome patrons over at patreon for your continued support me and my channel, if you’re interested in supporting my channel please check out the links in the description. If you enjoyed this video please consider subscribing, and as always, thanks for watching the hookup.
Info
Channel: The Hook Up
Views: 204,403
Rating: 4.9627609 out of 5
Keywords: home assistant, hassio, home automation, hass.io, smart home, diy, electronics, arduino, esp8266, nodemcu, wemos d1, automation, ubiquti, ubiqutiy, dream, machine, pro, unify, acl, iot, secure
Id: vz3u6E3Fxi8
Channel Id: undefined
Length: 33min 21sec (2001 seconds)
Published: Wed Feb 10 2021
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.