[idatum]

I recommend explicitly blocking internet access for Amcrest devices. I configured my camera with a static IP and blocked it in my PF rules with logging, and my camera model was making 1000s (16k in 24 hours) of DNS requests for config.amcrestcloud.com. I don't use any of their cloud services.

[hello_computer]

Rather than play whack-a-mole with filters, it's simpler to put mystery-meat devices on a separate VLAN+subnet that doesn't route. Firewall will keep the camera from accessing the internet, but does nothing to protect other hosts on the LAN.

The cloud thing can be disabled from their web UI or the HTTP API, but between all of the knock-offs out there (of any brand), and the eventual end of firmware updates, it's best not to trust any of this stuff.

[idatum]

Absolutely agree a VLAN is the better solution to block an entire network, and I do use one in my case (protecting my other VLANs). But I still need to explicitly block Amcrest cam because I also have an RPI on that VLAN doing image processing, which uploads to an external site; hence I can't block the entire VLAN.

[dmm]

A stateful firewall would allow your RPI to access the camera vlan/subnet while still blocking any outgoing connections from the cameras.

I use a Debian Linux router with nftables to achieve this in my homelab.

[k_roy]

This is doubly important now that devices are starting to use DNS over HTTPs

[hello_computer]

At the rate things are going, the only legal port on the internet is going to be 443/tcp. Use a different TCP port, get a visit from the cops. Send a UDP packet, black helicopters and unmarked vans are on their way.