About 6 months ago, I wrote about blocking my security cameras from talking to the Internet by moving them to a separate VLAN. Things have been working well, but after getting a USG, I decided to reduce the load on the router (using a VLAN required all traffic from my cameras to my Mac Pro to go through the router). My Mac Pro has 2 Ethernet ports, so I plugged the second port into another switch port that was set to the same VLAN as the cameras and give it an IP address on that VLAN. This would allow the cameras to talk directly to the Mac Pro without going through the router.
Perfect, I thought as everything was working well. However, when watching the logs on the router, I saw that the cameras were trying to talk to the Mac Pro’s primary IP address which was on a different VLAN. The router dropped the packets which was good, but it took me awhile to figure out what the cameras were doing. Basically the cameras were sending out UPnP packets to UDP port 1900 on the multicast address of their subnet and waited for replies. I had turned all UPnP off on the cameras, but they still kept sending packets. Why was the Mac Pro replying? I have the excellent BWS Systems HA Bridge installed on the Mac Pro to add Amazon Echo control to my Vera; in order to do this, HA Bridge listens for UPnP packets and then replies with the web address for device discovery. The bridge is configured to listen on all interfaces, but in its reply, it gives the primary IP address. While I’d like the bridge to only listen on the primary interface, most services listen on all interfaces.
Having learned and realized that the cameras could talk to any service on my Mac Pro, I kind of became concerned and looked for a way to block this. While I could go back to the router method, I decided to look at Mac OS X’s Packet Filter. I read a few articles and came up with the adding the following to
anchor "com.gruby" load anchor "com.gruby" from "/etc/pf.anchors/com.gruby"
I don’t know if
pf loads by default on all OS X systems, but it does on OS X Server. Then for my
/etc/pf.anchors/com.gruby, I have:
# Don't alert source about dropped packets set block-policy drop # Allow all on local loopback set skip on lo0 # Allow all on en0 set skip on en0 # Normalize and defragment scrub in all pass in quick on en0 all # Default deny policy block in all # Block in on en1 block in quick on en1 all block out quick from 10.0.2.100/32 to 188.8.131.52/4 block out quick from 10.0.2.100/32 to 10.0.2.255/32 pass out quick on en1 inet proto tcp from any to any port 554 pass out quick on en1 inet proto tcp from any to any port 80 pass out quick on en1 inet proto tcp from any to any port 85 pass out quick on en1 inet proto icmp block out quick on en1 all # Allow all outbound on en0 pass out on en0 all keep state
I’m sure that this could be cleaned up and some rules are redundant or unnecessary, but in my testing, these rules block all inbound and outbound traffic on my secondary Ethernet port except for the security software connecting to 3 specific TCP ports. Now when the cameras do the UPnP broadcast, they won’t get back any replies and no matter what, the cameras can’t make connections to the Mac Pro.
If I had to do my camera system over again (or had cameras drop in my lap), I’d go with UniFi cameras and install their NVR software in a VM. Ubiquiti updates their products frequently and listens to feedback, it appears. The cameras I got are made by a company that doesn’t care, doesn’t release updates, and doesn’t make a quality product. While the picture quality is adequate and they’ve held up for 4 years, I wouldn’t recommend them.
My concerns over the cameras doing things they shouldn’t kind of goes back to my post about keeping devices updated. Once a device is no longer supported, should it be trusted? New vulnerabilities are being discovered all the time? Should maintenance plans be offered to keep software updated?