Help Please..Need assistance stopping outbound connections!

[stockman]

Hi all. Created an account to post on this thread.
I've been using the excellent script Martineau created to block internet access on my ip cams. Router is rt-ac86u running latest Merlin firmware. Thanks to Martineau and everyone else's contribution here.

I was wondering if the experts here could answer a couple questions for me. Apologies if these were previously answered, but I was not able to find.

Note that I need to access my ip cameras via VPN so using the "block internet access" option on the router client list was not an option for me.

1) What is the difference between using Martineau's script and simply blocking TCP/UDP protocols for camera IPs in Network Services Filter? The only thing I've noticed is that a device restricted in Network Services can still ping to outside internet, where with Martineau's script ping is also blocked. I guess I'm also asking if it's practically necessary to run Martineau's script if the cameras IPs are already blocked in Network Services.

2) After blocking the cameras in Network Services and/or Martineau's script - what is the best way to test that the cameras are actually blocked from sending outbound traffic? It's easy to test with a blocked mobile phone or laptop connected to LAN - just try to load a webpage or ping google. I'm not sure how to replicate this test for a ip camera, however. I've setup the syslog to show all messages, but I'm not seeing any DROPS from the camera IPs. Maybe they're just not trying to access the WAN? I've also run the STATUS function of the script, which shows all camera IPs as blocked, but I'd really like to test using a more robust method.

3) If I'm accessing the cameras remotely using a VPN does it really make a difference if I use HTTPS or HTTP on TinyCam? (i.e. does HTTPS really add any additional security if I'm already using a VPN into my LAN?)

Thanks in advance for your help!

 

[martinr]

Hi all. Created an account to post on this thread.
I've been using the excellent script Martineau created to block internet access on my ip cams. Router is rt-ac86u running latest Merlin firmware. Thanks to Martineau and everyone else's contribution here.

I was wondering if the experts here could answer a couple questions for me. Apologies if these were previously answered, but I was not able to find.

Note that I need to access my ip cameras via VPN so using the "block internet access" option on the router client list was not an option for me.

1) What is the difference between using Martineau's script and simply blocking TCP/UDP protocols for camera IPs in Network Services Filter? The only thing I've noticed is that a device restricted in Network Services can still ping to outside internet, where with Martineau's script ping is also blocked. I guess I'm also asking if it's practically necessary to run Martineau's script if the cameras IPs are already blocked in Network Services.

2) After blocking the cameras in Network Services and/or Martineau's script - what is the best way to test that the cameras are actually blocked from sending outbound traffic? It's easy to test with a blocked mobile phone or laptop connected to LAN - just try to load a webpage or ping google. I'm not sure how to replicate this test for a ip camera, however. I've setup the syslog to show all messages, but I'm not seeing any DROPS from the camera IPs. Maybe they're just not trying to access the WAN? I've also run the STATUS function of the script, which shows all camera IPs as blocked, but I'd really like to test using a more robust method.

3) If I'm accessing the cameras remotely using a VPN does it really make a difference if I use HTTPS or HTTP on TinyCam? (i.e. does HTTPS really add any additional security if I'm already using a VPN into my LAN?)

Thanks in advance for your help!

Welcome to the forum. Neatly side-stepping all your questions, I wonder do you know about Skynet? I think it will do everything you need possibly a lot easier than you are currently doing it:

“Skynet can also be used to secure IOT device and prevent them from phoning home. It is the one stop shop for router security and the first line of defence in your home network.”

https://www.snbforums.com/threads/release-skynet-router-firewall-security-enhancements.16798/

 

[truglodite]

Hi all. Created an account to post on this thread.
I've been using the excellent script Martineau created to block internet access on my ip cams. Router is rt-ac86u running latest Merlin firmware. Thanks to Martineau and everyone else's contribution here.

I was wondering if the experts here could answer a couple questions for me. Apologies if these were previously answered, but I was not able to find.

Note that I need to access my ip cameras via VPN so using the "block internet access" option on the router client list was not an option for me.

1) What is the difference between using Martineau's script and simply blocking TCP/UDP protocols for camera IPs in Network Services Filter? The only thing I've noticed is that a device restricted in Network Services can still ping to outside internet, where with Martineau's script ping is also blocked. I guess I'm also asking if it's practically necessary to run Martineau's script if the cameras IPs are already blocked in Network Services.

2) After blocking the cameras in Network Services and/or Martineau's script - what is the best way to test that the cameras are actually blocked from sending outbound traffic? It's easy to test with a blocked mobile phone or laptop connected to LAN - just try to load a webpage or ping google. I'm not sure how to replicate this test for a ip camera, however. I've setup the syslog to show all messages, but I'm not seeing any DROPS from the camera IPs. Maybe they're just not trying to access the WAN? I've also run the STATUS function of the script, which shows all camera IPs as blocked, but I'd really like to test using a more robust method.

3) If I'm accessing the cameras remotely using a VPN does it really make a difference if I use HTTPS or HTTP on TinyCam? (i.e. does HTTPS really add any additional security if I'm already using a VPN into my LAN?)

Thanks in advance for your help!

Stockman, you mentioned because you need to access the cameras from a VPN, blocking internet for the cameras isn't an option... not so. The VPN effectively gives you local access so the cams will be accessible with the vpn even if they can't access the wan.

1) Network service filter isn't the proper way I think. 2) best way, since you have an 86u running Merlin, right click on the client in the webui and select block internet access. Lol it is that simple now that Merlin built that into the firmware. 3) The security of that connection depends on your VPN really. If you setup the vpn properly the using http or https won't matter much. If you want to encrypt communications to the camera on your lan (say your roommates like to hack), use https, otherwise don't. Outside hackers will just see encrypted VPN traffic.

 

[stockman]

Stockman, you mentioned because you need to access the cameras from a VPN, blocking internet for the cameras isn't an option... not so. The VPN effectively gives you local access so the cams will be accessible with the vpn even if they can't access the wan.

1) Network service filter isn't the proper way I think. 2) best way, since you have an 86u running Merlin, right click on the client in the webui and select block internet access. Lol it is that simple now that Merlin built that into the firmware. 3) The security of that connection depends on your VPN really. If you setup the vpn properly the using http or https won't matter much. If you want to encrypt communications to the camera on your lan (say your roommates like to hack), use https, otherwise don't. Outside hackers will just see encrypted VPN traffic.

Thanks for your reply.
Selecting "block internet access" in client list will also block VPN from accessing the camera (this was the first thing I tried). Thus the need for the script to selectively allow for VPN.

I very much wish it was this simple!!

 

[Martineau]

1) What is the difference between using Martineau's script and simply blocking TCP/UDP protocols for camera IPs in Network Services Filter? The only thing I've noticed is that a device restricted in Network Services can still ping to outside internet, where with Martineau's script ping is also blocked. I guess I'm also asking if it's practically necessary to run Martineau's script if the cameras IPs are already blocked in Network Services.

Parental Controls, Network Services Filter (NSFW) and custom scripts can all provide methods to restrict unsolicited outbound access at different blocking levels - scheduled, full or explicitly by service.

NOTE: You need to explicitly blacklist PING in the NSFW GUI - although not immediately intuitive

Originally both Parental Controls and NSFW were flawed - hence the creation of my custom script.
I think NSFW will now correctly block internet access via the explicit WAN interface (eth0/vlan2 etc.), whilst still allowing remote viewing via the VPN servers (tun2+)?

However, I don't believe you can easily block (by default) ALL non-VPN traffic yet still allow exceptions for say remote NVR servers/Outbound SMTP Port emails without using my script?

2) After blocking the cameras in Network Services and/or Martineau's script - what is the best way to test that the cameras are actually blocked from sending outbound traffic? It's easy to test with a blocked mobile phone or laptop connected to LAN - just try to load a webpage or ping google.
I'm not sure how to replicate this test for a ip camera, however. I've setup the syslog to show all messages, but I'm not seeing any DROPS from the camera IPs. Maybe they're just not trying to access the WAN? I've also run the STATUS function of the script, which shows all camera IPs as blocked, but I'd really like to test using a more robust method.

Not ALL cameras are nefariously 'phoning-home', some simply perform a check for a new firmware (which is a good thing - right?), but 80% of my cameras do attempt to access remote servers, hence the use of my script's 'logdrop' option.
P.S. I'm not sure which clandestine methods would be deployed by the IP cameras that cannot be replicated by your (comprehensive) tests using a laptop?

3) If I'm accessing the cameras remotely using a VPN does it really make a difference if I use HTTPS or HTTP on TinyCam? (i.e. does HTTPS really add any additional security if I'm already using a VPN into my LAN?)

Running a MITM attack on an HTTP connection when on the same LAN is basically trivial.

So, is your LAN 'secure' or 'trusted'?...and because someone that has access to your LAN says they are trustworthy is this always true?

e.g. suppose you have a security camera that covers the back garden, if HTTPS isn't used on your LAN, could your IP savvy teenager sniff the http://IPCAM password to disable the 'motion-trigger' recording before popping out after curfew to an 'all-night-rave', then reinstate the 'motion-trigger' recording on their cunning undetected return at dawn? - not as far-fetched as you would think!

 

[stockman]

Parental Controls, Network Services Filter (NSFW) and custom scripts can all provide methods to restrict unsolicited outbound access at different blocking levels - scheduled, full or explicitly by service.

NOTE: You need to explicitly blacklist PING in the NSFW GUI - although not immediately intuitive

Originally both Parental Controls and NSFW were flawed - hence the creation of my custom script.
I think NSFW will now correctly block internet access via the explicit WAN interface (eth0/vlan2 etc.), whilst still allowing remote viewing via the VPN servers (tun2+)?

However, I don't believe you can easily block (by default) ALL non-VPN traffic yet still allow exceptions for say remote NVR servers/Outbound SMTP Port emails without using my script?

Not ALL cameras are nefariously 'phoning-home', some simply perform a check for a new firmware (which is a good thing - right?), but 80% of my cameras do attempt to access remote servers, hence the use of my script's 'logdrop' option.
P.S. I'm not sure which clandestine methods would be deployed by the IP cameras that cannot be replicated by your (comprehensive) tests using a laptop?

Running a MITM attack on an HTTP connection when on the same LAN is basically trivial.

So, is your LAN 'secure' or 'trusted'?...and because someone that has access to your LAN says they are trustworthy is this always true?

e.g. suppose you have a security camera that covers the back garden, if HTTPS isn't used on your LAN, could your IP savvy teenager sniff the http://IPCAM password to disable the 'motion-trigger' recording before popping out after curfew to an 'all-night-rave', then reinstate the 'motion-trigger' recording on their cunning undetected return at dawn? - not as far-fetched as you would think!

On NSFW: I checked again last night and wasn't able to find an option for PING. Confirmed that if I block camera IP with NSFW, VPN access is still allowed. I don't have a NVR and I'm not doing SMTP emails so I can't confirm your last point. (Edit: The bottom line is that your script seems more secure because it also blocks PING, but is it stronger in other ways that I'm not aware of - or is NSFW block sufficient? Does PING matter? No idea of the repercussions of my camera pinging a nasty IP address)

On logdrop: I tested again using my mobile phone connected via WIFI to LAN. If I block via NSFW only (no script) I see DROP entries in the router log every time I try to access the internet on the phone. However, if I unblock in NSFW and block only in the script, the phone is still blocked from internet (i.e. won't load a website) but the router doesn't log my attempts - even after executing logdrop. Not sure why this is. I say all of this because I know for sure that one of my cameras has a habit of reaching out to Chinese IPs and I'm curious to see those entries in the log, but they don't with the script.

On HTTPS: Okay, so if I trust everyone that can access my WIFI/LAN and also have reasonable confidence that my WPA2 password is strong HTTP vs HTTPS doesn't matter.

Thanks again.

 

[ColinTaylor]

That's NSF (Network Services Filter), not NSFW (not safe for work). Freudian slip?



[Yes, I know the iptables chain is named NSFW ]

 

[Martineau]

On NSFW: I checked again last night and wasn't able to find an option for PING.

ICMP Echo Requests (aka "PING") is ICMP Type 8

I said it was obscure and not exactly intuitive for novices!

If I unblock in NSFW and block only in the script, the phone is still blocked from internet (i.e. won't load a website) but the router doesn't log my attempts - even after executing logdrop. Not sure why this is. I say all of this because I know for sure that one of my cameras has a habit of reaching out to Chinese IPs and I'm curious to see those entries in the log, but they don't with the script.

Assuming you have indeed invoked my script with the 'logdrop' directive, can you check the iptables logdrop chain

iptables  --line -t filter -nvL   logdrop

and the MyIPCAMs chain

./IPCamsBlock.sh status | grep -o "^.*logdrop"

Does PING matter? No idea of the repercussions of my camera pinging a nasty IP address

Who knows the ingenuity of hackers?, but you could easily get your retaliation 'in first' by initiating a PING-flood to their servers!

 

[xtropodx]

The Wiki https://github.com/RMerl/asuswrt-merlin/wiki has loads of info e.g. https://github.com/RMerl/asuswrt-merlin/wiki/Iptables-tips



You must initially set up SSH access to the router via the GUI, then start a session using PuTTY (although XShell is highly recommended) then if you can cut'n'paste into an editor then you should be good to go.

So this post by RMerlin simply expands on the instruction on the Wiki for creating a sample script:

https://www.snbforums.com/threads/help-with-custom-scripts.34950/#post-283099

If you are using Windows then WinSCP is (in my view) an essential tool for expanding the capabilties of the router using scripts. You can move around the router file system, viewing, editing, etc. and even create backup copies of your scripts using drag'n'drop between a windows folder and the router.
You can even execute/test your scripts from within WinSCP by simply right clicking on the script in the GUI.

It has probably taken me longer to type this than it will take for you to actually set up SSH and create your first 'Hello World' test script on the router!

Anyway, I wrote a script for my family/colleagues who also have the same security concerns. So as shown in the script help, you simply only need to create/maintain a text file containing one line defining the I/P addresses of your cameras...

e.g. say you have 13 cameras to be blocked from accessing the Internet but still remain accessible for remote viewing over the VPN.

/jffs/configs/IPGroups

CAMERAS  192.168.1.196,  192.168.1.15-192.168.1.20,  192.168.1.50:192.168.1.55

/jffs/scripts/IPCamsBlock.sh

EDIT: 08/01/2018 v1.04 Added 'logntp' directive and use separate custom iptables chain
EDIT: 01/02/2018 v1.05 Added 'wanip/usewanip' directives for external NVR
EDIT: 09/06/2018 v1.06 Added 'mac' directive and filter LAN NTP requests
EDIT: --/--/2018 v1.07 Allow 'relaxed' .csv format for import
EDIT: 11/09/2018 v1.08 Added 'mail=' directive
EDIT: 12/09/2018 v1.09 Added 'logscan' directive
EDIT:--/--/2018 v1.10 Allow multiple 'wanip=xxx.xxx.xxx.xxx[….]'
EDIT:03/11/2018 v1.11 Fix possible globbing issue and streamline code.
EDIT:17/11/2018 v1.12 Fix detect 'other2wan' rule (Dual-WAN environments)

https://pastebin.com/KUwcbMC4

Hosted on pastebin as life is too short to tediously identify why posting the script in-line triggers the forum blocker


P.S. It is considered good practice to keep custom scripts separate and call them from the system scripts as necessary rather than copy all the code in say an existing 'firewall-start' script!
So you would simply add the call to run '/jffs/scripts/IPCamsBlock.sh' from 'firewall-start' by adding the line

/jffs/scripts/IPCamsBlock.sh init

Then if anything goes wrong, you can just disable 'IPCamsBlock.sh' rather than inadvertently breaking 'firewall-start'

Quoting this so can save the link, as it's very hard to locate .

I've just gone to the trouble of updating a crap load of stuff, including this script. And I'm experiencing issue with it.

If I run;

/jffs/scripts/ipcamsblock init

It is allowing full access of the listed IPs to anywhere. It's not blocking them at all.

But if I run

/jffs/scripts/ipcamsblock status

It blocks them properly.
I thought perhaps line endings may be causing problem, but not sure how I can check that & I've redone the script from source several times now to make sure but still same issue. Or am I missing a set of initialization steps that must now be followed, as running the init command isn't consistent.

Also if I change any single device in the routers webui, like block or unblock internet access, it resets the script for ALL IPs listed in IPGroup & I have to redo

/jffs/scripts/ipcamsblock status

How can make sure any changes to router etc this script will stay in place? I don't remember or can't find how did it last time .

Have

#!/bin/sh
sh /jffs/scripts/firewall start skynetloc=/tmp/mnt/SKYNET/skynet # Skynet Firewall Addition
sh /jffs/scripts/IPCamsBlock.sh init

placed in both firewall-start & wan-start
I am running Skynet for different reasons.

I feel my previous setup was working great, but can't go back, & would like this running seamlessly like it was previously. Loved using this would just like to get it working properly again .

 

[Martineau]

If I run;

/jffs/scripts/ipcamsblock init

It is allowing full access of the listed IPs to anywhere. It's not blocking them at all.

But if I run

/jffs/scripts/ipcamsblock status

It blocks them properly.

Unix filenames are case sensitive, so

/jffs/scripts/ipcamsblock init

does not reference/execute the same script as

/jffs/scripts/IPCamsBlock init

To ensure you are able to distinguish between internal system scripts (such as 'wan-start' etc.) I recommend all end-user-written custom scripts have the suffix '.sh' (you can always create an alias etc. if you wish to save typing the full name of the script when executing it from the command line.

sh /jffs/scripts/IPCamsBlock.sh init

placed in both firewall-start & wan-start

There is no need to include the above in both 'wan-start' and 'firewall-start', 'firewall-start' should suffice.

Ensure you only have script '/jffs/scripts/IPCamsBlock.sh'

 

[ProfEngr]

I must have missed a click somewhere. When I pasted the script to IPCamsBlock.sh I saved it and chmod 0755 ok. When I type ./IPCamsBlock.sh init into the terminal window I get a file not found error even though ls -l shows it exists in jffs/scripts at 28KB in size. If I type sh IPCamsBlock.sh init I get a bunch of errors.
Asus RT-AC86U on Merlin 384.12.

 

[ColinTaylor]

I must have missed a click somewhere. When I pasted the script to IPCamsBlock.sh I saved it and chmod 0755 ok. When I type ./IPCamsBlock.sh init into the terminal window I get a file not found error even though ls -l shows it exists in jffs/scripts at 28KB in size. If I type sh IPCamsBlock.sh init I get a bunch of errors.

https://www.snbforums.com/threads/h...outbound-connections.38086/page-8#post-470929

 

[ProfEngr]

https://www.snbforums.com/threads/h...outbound-connections.38086/page-8#post-470929

Thanks. That got it sorted.

 

[stockman]

Hi all,
Since my last post I've continued to run an OpenVPN server on my AC86U along with the excellent script offered in this thread to ensure my IP cameras aren't dialing home.

Everything was working swimmingly until last week when out of nowhere I'm no longer able to access the camera feeds or use the internet while on 4G connected to the VPN.

OpenVPN on the android still instantly connects to the router and the app shows data being transferred back and forth, but like I said no internet/camera feeds on the phone's 4G. Another interesting aspect is that TinyCam is still able to ping my cameras despite not being able to access the feed.

The router System Log doesn't show anything significant for "ovpn-server". It's the same two dozen lines or so I'm used to seeing whenever I connect to the server. There also are no additional error/alert entries when I try to access internet/cameras on the phone.

The only thing notable is two warnings when I connect to the VPN server: "link-mtu is used inconsistently..." and "[my router's username]is used inconsistently..." After googling it seems that those messages aren't too big of a deal and have something to do with the negotiation process of OpenVPN. Obviously, I could be wrong.

I already have the router log set to show the most detail...is there a separate, more detailed OpenVPN log available somewhere else that might provide more clues (like through SSH)? The OpenVPN log on my phone wasn't helpful. (I'm looking for some sort of error)

I'm beginning to suspect that either my 4G carrier or home ISP has decided to block my VPN. I say this because there were zero software or configuration changes made to the router before the problem started. I even updated to the latest Merlin after the problem started thinking it may help.

Thanks for your thoughts...I hope this isn't too off-topic. I suppose there is a remote chance that the script mentioned in this thread could be causing the issue even though no changes were made to it or anything else.

 

[anderson]

Apologies for reviving this dormant topic, but I figured it was preferable to starting a new one, as I was hoping to get some assistance related to this.

I'm using Asuswrt-Merlin on my RT-AC68U, and I've followed the posts and instructions here to setup Martineau's IPCamsBlock script

• added my camera IP addresses to /jffs/configs/IPGroups
• added the script itself to /jffs/scripts/IPCamsBlock.sh
• and initialized IPCamsBlock in firewall-start

I've tested it by running sh IPCamsBlock.sh, which returned this:

num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     udp  --  br0    eth0    anywhere             anywhere             udp dpt:ntp
3        0     0 DROP       all  --  br0    !tun2+  192.168.1.120        anywhere
5        0     0 DROP       all  --  br0    !tun2+  192.168.1.123        anywhere
7        0     0 DROP       all  --  br0    !tun2+  192.168.1.124        anywhere
9        0     0 DROP       all  --  br0    !tun2+  192.168.1.125        anywhere

I also entered a desktop PC and mobile phone IP to the IPGroups, and they were blocked from internet access, so I'm assuming I did set it up right.
(I guess I should also disable the Block Internet Access option for the devices in question, now that this is done right?)

However, I recently realized that my Foscam cameras can still be viewed via the Foscam app, which seems to suggest they are somehow still able to access the Internet. (I can view their live feeds even on mobile data.)

How is this so? Did I do something wrong in the script setup?
Thanks in advance for any help or advice here.

 

[Martineau]

Apologies for reviving this dormant topic, but I figured it was preferable to starting a new one, as I was hoping to get some assistance related to this.

I'm using Asuswrt-Merlin on my RT-AC68U, and I've followed the posts and instructions here to setup Martineau's IPCamsBlock script

• added my camera IP addresses to /jffs/configs/IPGroups
• added the script itself to /jffs/scripts/IPCamsBlock.sh
• and initialized IPCamsBlock in firewall-start

I've tested it by running sh IPCamsBlock.sh, which returned this:

num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     udp  --  br0    eth0    anywhere             anywhere             udp dpt:ntp
3        0     0 DROP       all  --  br0    !tun2+  192.168.1.120        anywhere
5        0     0 DROP       all  --  br0    !tun2+  192.168.1.123        anywhere
7        0     0 DROP       all  --  br0    !tun2+  192.168.1.124        anywhere
9        0     0 DROP       all  --  br0    !tun2+  192.168.1.125        anywhere

I also entered a desktop PC and mobile phone IP to the IPGroups, and they were blocked from internet access, so I'm assuming I did set it up right.
(I guess I should also disable the Block Internet Access option for the devices in question, now that this is done right?)

However, I recently realized that my Foscam cameras can still be viewed via the Foscam app, which seems to suggest they are somehow still able to access the Internet. (I can view their live feeds even on mobile data.)

How is this so? Did I do something wrong in the script setup?
Thanks in advance for any help or advice here.

At first glance, since there are no hits shown against the firewall rules created by my script. then it would appear that the blocking rules are ineffective?

e.g. my router has been up only 4 days but shows successful outbound blocking of the designated camera devices. (You can enable 'logdrop' to log the blocks to Syslog)

./IPCamsBlock.sh status

(IPCamsBlock.sh): 29622 v1.13 I/P Cameras Firewall blocking.... status


Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination       
3     512K   82M MyIPCAMs   all  --  br0    *       0.0.0.0/0            0.0.0.0/0         

Chain MyIPCAMs (1 references)
num   pkts bytes target     prot opt in     out     source               destination       
1     6524  496K ACCEPT     udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:123
2    15790  947K DROP       all  --  br0    !tun2+  10.88.8.120          0.0.0.0/0         
3        0     0 DROP       all  --  br0    !tun2+  10.88.8.121          0.0.0.0/0         
4        0     0 DROP       all  --  br0    !tun2+  10.88.8.122          0.0.0.0/0         
5     251K   52M DROP       all  --  br0    !tun2+  10.88.8.123          0.0.0.0/0         
6    30942 1857K DROP       all  --  br0    !tun2+  10.88.8.125          0.0.0.0/0         
7        0     0 DROP       all  --  br0    !tun2+  10.88.8.148          0.0.0.0/0         

(IPCamsBlock.sh): 29622 I/P Cameras Firewall blocking status request completed.

P.S. I only use the IP Cam Viewer app so not familiar with the Foscam app - is it using P2P?

If you remove my script and only use the GUI to block the cameras, does the Foscam app still gain access?

 

[anderson]

Hi Martineau, thanks for the quick reply! Sorry, I copied the wrong lines previously (those were from re-initializing the script).

This was what I got after running sh IPCamsBlock.sh status:

(IPCamsBlock.sh): 2879 v1.12 I/P Cameras Firewall blocking.... status


Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
3     6195  520K MyIPCAMs   all  --  br0    *       0.0.0.0/0            0.0.0.0/0

Chain MyIPCAMs (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1      136 10336 ACCEPT     udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:                                                                                                                                       123
2        0     0 DROP       all  --  eth0   *       0.0.0.0/0            192.168.1.120        state NE                                                                                                                                       W
3        0     0 DROP       all  --  br0    !tun2+  192.168.1.120        0.0.0.0/0
4        0     0 DROP       all  --  eth0   *       0.0.0.0/0            192.168.1.123        state NE                                                                                                                                       W
5      390 23400 DROP       all  --  br0    !tun2+  192.168.1.123        0.0.0.0/0
6        0     0 DROP       all  --  eth0   *       0.0.0.0/0            192.168.1.124        state NE                                                                                                                                       W
7       77  4620 DROP       all  --  br0    !tun2+  192.168.1.124        0.0.0.0/0
8        0     0 DROP       all  --  eth0   *       0.0.0.0/0            192.168.1.125        state NE                                                                                                                                       W
9        0     0 DROP       all  --  br0    !tun2+  192.168.1.125        0.0.0.0/0

(IPCamsBlock.sh): 2879 I/P Cameras Firewall blocking status request completed.

(192.168.1.120 is an NVR, while 192.168.1.125 was turned off at the time.)

P.S. I only use the IP Cam Viewer app so not familiar with the Foscam app - is it using P2P?

I don't think it is, as the Foscam cameras are setup to be wired only (no wifi info), but I can still access their live feed while disconnected from the home network and using mobile data.

If you remove my script and only use the GUI to block the cameras, does the Foscam app still gain access?

Yeah, after I enabled the Block Internet Access option on the devices, and restarted them, they were no longer accessible on the app. :/

 

[Wisiwyg]

I have 2 EZViz (doorbell, motion floodlight/cam) and a Yoluke (dome) wifi cameras on my network, all 3 from China manufacturer. I have them blocked in parental controls by MAC ID. I've seen them change the first 3 sets of their MAC to get around the block, last 3 remain consistent. I've put them on a separate Guest network, but they're so dispersed they don't always stay connected, and when I block both MACs they loose connectivity to BlueIris almost like they need to phone home to continue to work properly. Next house I build I'll wire for POE to each cam location.

This is the primary reason I'm looking forward to Guest 1 bugs getting worked out - so I can put them on mesh Guest 1 with nodes close to the cameras with weak transmit power. They can receive, but they can't transmit back.

 

[Jeffrey Young]

I've seen them change the first 3 sets of their MAC to get around the block, last 3 remain consistent.

Sneaky buggers!! I am getting ready to use this script. I will be mindful of this little trick. The very fact the cameras are doing this behavior is troubling.

 

[anderson]

My cameras aren't blocked by MAC address though, only by IP address via Martineau's script.

I'm a little perplexed that I'm still able to view my Foscam camera through its app, even when I am completely disconnected from my home network, and the script status does show packets being dropped on that camera.
Does that mean it's P2P and that overrules the blocking rules implemented by the script?