I have a camera that I can access from the manufacturer's cloud platform through a phone app. At the same time, I possess a router running Linux which I want to program to block the camera's access to the internet. This should happen at my request and not as a permanent rule. I am using the firewall's iptables command to accomplish this but the frustrating situation is when this is not working. I insert two rules in the firewall's forward chain like this:

iptables -I FORWARD -s camera_local_ip_addr -j DROP
iptables -I FORWARD -d camera_local_ip_addr -j DROP

Occasionally this works, especially if I reboot the camera having the rules already inserted or when the connection was recently established. But most of the times it's not working for some unknown reason to me. For example, I insert the rules, the connection drops and after 5 hours, let's say, when I remove the rules, the connection is re-established as expected but from that moment I cannot block it anymore using the same procedure. Sometimes it's not working at all by inserting these rules. I tried to monitor the firewall traffic by using:

watch -n 1 iptables -L FORWARD -nvx

which shows an increasing number of packets for the first rule; this should mean that the packets are being dropped but in fact, I can still access the camera from the mobile app out of the network (with the wifi turned off). At some point, I thought this might be because of the DHCP lease and inserted a rule to allow the UDP traffic on ports 67 and 68 but it didn't work. However, I think the DHCP requests are not passing through the FORWARD filter anyway.

So my questions are: why is that this procedure works sometimes but not most of the times? And, is there any other method to block programmatically the internet access from/to my camera?
Thanks in advance!

  • 1
    Unplugging. It also comes with the bonus of giving coworkers a simple method of visually confirming "this camera is currently not recording". – anx Jan 21 '19 at 9:24
  • This won't be a solution since the router needs to run a script that blocks the traffic when an event occurs, such as detecting the presence. When the iptables is working as it should, the camera will show in the app that is offline which is the desired outcome. – Mike Jan 21 '19 at 9:37
  • Do you have an ESTABLISHED,RELATED accept rule as the first rule? Then that's why you can't stop an already working connection. Note that your second rule probably won't work because the destination address of incoming packets from the internet is still you public IP address at that time, the NAT rule is applied after the forwarding decision. You'd have to block in the POSTROUTING I think. However preventing outgoing connections should be enough. – wurtel Jan 22 '19 at 12:55
  • @wurtel Thanks for your inputs! I have a ESTABLISHED, RELATED rule but it's not the first one. My first rules in the FORWARD table are the ones I posted. That is why I used the -I parameter. While regarding the second rule, as far as I know, there is a NAT in the PREROUTING, otherwise the router would not be able to decide if the packet should be routed to INPUT or to FORWARD. However, you are right by suggesting that my second rule would be redundant in my situation. – Mike Jan 23 '19 at 13:43

As a generic approach towards increasing reliability of your complicated iptable rules, apply a DROP policy and explicitly allow (whitelist) everything you want (a simple example would be: allow icmp, dhcp and everything from DHCP-assigned addresses)

For your current problems, consider the following methods the camera could use to avoid your current rules:

  1. connect via IPv6, when you only restricted IPv4 traffic
  2. use multiple addresses, when you only restricted one (yes, some devices do this even when they only have one physical ethernet port)
  3. on DHCP errors, fall back to a hardcoded default address that happens to be from the same subnet as your DHCP-assigned ones, and thus has its traffic forwarded regardless
| improve this answer | |
  • Thanks for your advice! The FORWARD chain already has a DROP policy by default. Somehow, probably by using one of your approaches, the camera is still passing through the filters. I think the best way to find out is by sniffing the packets with Wireshark and hopefully figure out the flow. – Mike Jan 21 '19 at 13:30
  • You can also block traffic from your camera using -m mac --mac-source xx:xx:xx:xx:xx:xx, you could match this in the PREROUTING table. – wurtel Jan 23 '19 at 14:37
  • @wurtel thanks for your suggestion but not working... – Mike Jan 28 '19 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.