VLAN Firewall Rule Enough for Secure Setup?

[AlphaCentauri]

Hey everyone, I have my main switch with one port specified as a Vlan for my cameras which is connected to another switch with a blue iris pc and all of the cameras. As a networking noob i’m a little confused about one thing.

To setup my first cam, I first disabled WAN access by setting a false gateway ip in the NIC properties under ipv4 settings. After messing with all of the camera settings I then set a different static ip and set another false gateway ip in the camera settings. I then changed the ip address on my NIC to the default settings to get internet on the PC. After setting a firewall rule for WAN out specifically for the camera, I then fixed the false gateway ip on the camera.

My question is, was all of this unnecessary since I setup a Vlan? For the rest of the cameras, could I just setup the Vlan with a Wan out firewall rule so that everything connected to the switch on that port only has LAN access only?

Any help would be greatly appreciated, thanks!

 

[Alan commike]

Yes, a VLAN with firewall rule is sufficient. Create a VLAN that doesn't have outbound WAN access. Depending on which VLAN your BI server sits, you'll need rules for it to reach the camera ports and the cameras to reach it, or for you to reach BI if it's on the same VLAN as the cameras. It may go something like this:

1) Put your computer on the 192.168.1.0/24 network that Dahua defaults to
2) Log in to the camera and set its IP to whatever you need on your secure VLAN
3) Double check the IP you put in, write it down, and hit Save
4) Set your computer back to "normal"
5) Access the camera on the secure VLAN to make sure it's reachable
6) Pull the power from the camera, let it boot, if you can still reach it your golden

I can't recall if you need to reboot for the IP to take effect or simply edit the Network settings. I think once you hit Save it'll make the change.

The Dahua and Amcrest cameras are pretty chatty and persistent, but nothing of too much concern. Here's what I see blocked in the last few minutes:

devaccess.easy4ipcloud.com (54.148.167.79)
www.easy4ipcloud.com (54.241.203.224)
www.easy4ipcloud.com (54.215.119.215)
www.easy4ipcloud.com (54.215.94.78)
devaccess-or.easy4ipcloud.com (54.71.216.134)
www.easy4ipcloud.com (54.241.202.176)
www.easy4ip.com (54.149.140.132)

One area that you might need to deal with is ntp time sync. If you're not allowing the camera to reach out to the internet for ntp, you'll either need a local LAN source that the secure VLAN can reach or punch pinholes in your firewall for originating ntp (usually 123/UDP) on that VLAN.

 

[AlphaCentauri]

Thanks for the confirmation! Luckily, I was following the steps you outlined exactly. How are you checking what ips are being blocked? So far the times been in sync in blue iris so hopefully I don't have to create any firewall rules for NTP, i'm not sure if that will still be the case if there's any power outages though.

 

[Alan commike]

How are you checking what ips are being blocked?

I have a commercial hardware firewall on my network. My home environment is atypical. Most people don't have a full height 19" rack in their basement.

Another low-cost option that will give you plenty of feedback is something like pihole. It's not as safe as VLANs and firewalls, in exchange it's fairly simple to use and setup if you are familiar with Linux. The adblock portions are pretty popular in some circles too.

So far the times been in sync in blue iris so hopefully I don't have to create any firewall rules for NTP, i'm not sure if that will still be the case if there's any power outages though.

Clocks on all electronics will drift over time, some faster, some slower. If you have multiple cameras you'll want them all to have exactly the same time for when you need to view a particular point in time across the cameras.

 

[AlphaCentauri]

I have a unifi setup with a USG Pro, would I be able to set something up using that instead of a raspberry pi to check which ips are being blocked? Also, what would an example of a local LAN source be to reach out to NTP instead of making firewall rules? Thanks!

 

[redfive]

I often use Edgerouters, and the router can act a NTP server, the same should be for the USG, simply declare the ip address of the vif as NTP server in the NVR/cameras (the same ip address as the default-gateway), of course, UDP port 123 must be allowed on the system from that VLAN. With ZBFW, from NVR/cams VLAN to self (local) zone something like

Spoiler: fw

jonatha@er6p# show firewall name 011nvr_2_003self
 default-action drop
 enable-default-log
 rule 10 {
     action accept
     state {
         established enable
         related enable
     }
 }
 rule 20 {
     action accept
     destination {
         group {
             port-group DNS_PORT
         }
     }
     protocol tcp_udp
     source {
         group {
             network-group NVR
         }
     }
 }
 rule 30 {
     action accept
     destination {
         group {
             port-group NTP_PORTS
         }
     }
     protocol udp
     source {
         group {
             network-group NVR
         }
     }
 }
 rule 40 {
     action accept
     destination {
         group {
             port-group DHCP_PORT
         }
     }
     protocol udp
     source {
         port 68
     }
 }
[edit]

 

[Alan commike]

@AlphaCentauri, what @redfive says. You'll need to find someone (Unifi support?) that will help you understand how to view logs in the USG Pro. It should have a mechanism to show the rules that trigger a block action.

 

[catcamstar]

@AlphaCentauri, what @redfive says. You'll need to find someone (Unifi support?) that will help you understand how to view logs in the USG Pro. It should have a mechanism to show the rules that trigger a block action.

This is something you can do yourself: when you make a new firewall rule, there is a "default action" (eg drop all) which you can send to the log (disabled by default): example :

So you enforce the "drop all" default rule, enable only the actions you do want, and then you start "tail -f /var/log/messages". You'll see all the dropped packets to identify whether (or not) you'd need them.

Do not forget to turn off "default logging" afterwards, as it does consume some cpu and for sure disk.

Good luck!
CC

 

[AlphaCentauri]

Thanks everyone for all of the great info! Will definitely be checking whats being blocked as soon I setup the NTP firewall rules. I think i'm starting to grasp how to configure it, but one thing that still confuses me is, which category should I put those NTP firewall rules under that redfive specified? Wan Out? Theres also Wan in, wan local, lan in, lan out, and lan local.


Looking at the steps just to setup the NTP firewall rules makes me less confident that I setup my cameras firewall rules correctly.. Does this look right at all? (I also used these same firewall rules for the PC running blue iris.)

Name: Camera 1

Action: Reject

IPv4 Protocol: All

Logging: Enabled (Just until SSH in and check)

States: Says New, Established, Invalid, or Related - Didn’t check any

IPsec: Don’t match on IPsec packets

Source: Put Cameras IP and MAC

Destination: Has address/port group selected by default which you have to input ipv4 address group and port group but I just left this blank.

 

[catcamstar]

Thanks everyone for all of the great info! Will definitely be checking whats being blocked as soon I setup the NTP firewall rules. I think i'm starting to grasp how to configure it, but one thing that still confuses me is, which category should I put those NTP firewall rules under that redfive specified? Wan Out? Theres also Wan in, wan local, lan in, lan out, and lan local.

The ipcamtalk forum is not the correct space to discuss ubiquity FAQ's, but there are tons of threads on there forum which explain the firewall naming convention in much detail.

I personally liked the following diagram:

In short:
X.local is for traffic arriving AND staying in that interface
X.in is for traffic coming IN from that interface and going TO the routing
X.out is for traffic coming in FROM the routing and leaving the interface

Off course you have different choices, like allowing NTP on the WAN.IN (so all devices can use it on your network), or allowing NTP on camsvlan.IN. It all depends on how many rules you want to manage.

Good luck!
CC

 

[Constantin]

The Dahua and Amcrest cameras are pretty chatty and persistent, but nothing of too much concern.
...
One area that you might need to deal with is ntp time sync. If you're not allowing the camera to reach out to the internet for ntp, you'll either need a local LAN source that the secure VLAN can reach or punch pinholes in your firewall for originating ntp (usually 123/UDP) on that VLAN.

Pretty chatty, you say? I turned off UPNP, Genetec, and P2P, yet days later each of my cameras tries to reach dahuas servers over 670,000 times a day.... and Genetec, P2P, etc. are turned back on. The only explanation I have is that these services turn back on by default when the POE power cycles, as we had a recent power outage. I'll turn it all off again.

I am researching setting up a VLAN to limit the impact of all this SPAM on the rest of my network, even if the router (and the pi-holes) stop it. As for time stamps, I consider the need for the cameras to have accurate time to be rather less than pressing. I'd rather do all the time burn-in at the BI since then all the videos will be running on the same clock. Similarly, I prefer having my day/night switchover get dictated by actual lighting conditions rather than relying on a clock.

 

[sebastiantombs]

If you ever need to provide video as evidence suitable for Court you'll find accurate and consistent time stamps a must. I realize you may feel that will never happen, but stranger things do happen.

 

[Constantin]

It precisely because a consistent, accurate time stamp is a must that I prefer using the clock in BI to annotate the video with a burned-in time stamp, as well the the BI recording timeline in general.

The crystals inside Dahua cams (if they use crystals, they may be using resonators, for all I know) are not going to run the same speed depending on which clock is hot, which is in the shade, etc. None of these clocks can be relied to be on the same second even unless they connect to a NTP server several times a day to correct for drift. I'd rather avoid all that and have one recording basis that is consistent from cam to cam.

I am also flummoxed that these cams would attempt to reach the mothership 670,000+ each on every day, that's roughly 8 times a second!

 

[bp2008]

You can run NetTIme from www.timesynctool.com on the Blue Iris server and have cameras sync from that.

Simply setting the camera's IPv4 gateway and DNS to fake addresses isn't necessarily enough to keep cameras off the internet even if the settings do save properly. IPv6 is becoming more and more common too and for a lot of reasons it is much harder to limit internet access using this. The only way I would really trust to keep cameras off the internet anymore is to put them on a VLAN or separate physical LAN with no WAN access.

 

[sebastiantombs]

The clock in BI is not sufficient. All cameras need their internal clocks synced to the same time source. Setting up an NTP server on a PC is no problem and uses very little overhead. Plus using the camera time stamp saves a small amount of CPU cycles since BI isn't modifying the video. That modification, by BI, is exactly what you need to avoid for evidentiary purposes.

I've been watching this conversation and the simplest solution is a separate NIC and subnet for the cameras. That firewalls them, totally, from internet access in the easiest way possible. No VLAN rules to configure and access rules for special cases, that sometimes have unanticipated results. It may not be as "elegant" but it is definitely secure and very easy to do.