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.
