Fun with Packet Filtering

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 /etc/pf.conf,

    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 224.0.0.0/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?