Help Please..Need assistance stopping outbound connections!

[Krvicch]

You can try this IPSET technique to have the router automatically collate the dynamic list of IPs associated with the domain.

As a proof of concept, enter the following commands:

ipset create Gmail_smtp hash:ip

echo ipset=/smtp.gmail.com/Gmail_smtp >> /jffs/configs/dnsmasq.conf.add
service restart_dnsmasq

nslookup smtp.gmail.com

ipset list Gmail_smtp

IPSET 'Gmail_smtp' will now contain a 'current' list of IPs associated with domain 'smtp.gmail.com'
NOTE: This list of IPs will be lost @ Reboot unless it is appropriately saved/restored etc.

So you should now use in the script this rule

Firewall $ACTION $CHAIN $FWRULENO -i br0 -o $WAN_IF -m set --match-set Gmail_smtp dst -j ACCEPT

NOTE: Any LAN device references to 'smtp.gmail.com' will cause the IPSET to be updated. (Clearly you can also force the refresh by scheduling the 'nslookup' command say once a day although this is not normally required.)

Thank you @Martineau !

With a few tweaks for my setup, this is working great! One question ... is there any benefit to saving and restoring the Gmail_smtp ipset list versus just rebuilding it upon rebooting the router with a simple script for that purpose?

Thanks again for your help

 

[Martineau]

Thank you @Martineau !
... is there any benefit to saving and restoring the Gmail_smtp ipset list versus just rebuilding it upon rebooting the router with a simple script for that purpose?

Well it depends!

Assuming you reboot say once a week, then it probably means the IPSET isn't full of potentially obsolete IP addresses.
So if you didn't require the save/restore function, then whilst it is quite drastic, the houskeeping is comprehensive.

P.S. Google probably aren't retiring and creating new SMTP servers every day so the size of the IPSET would be fairly static anyway.

 

[wisebear]

@Martineau: Thank you for the script. Being a total newbie with firewall rules I am wondering whether your script can also be used to block internet access for various other IoT devices (e.g. smart thermostats, switches, lights etc.)?

I am thinking how to configure my network for home automation devices. Since it is not that easy to set up VLANs with Merlin one option might be to use your script to isolate them from internet and keep the possibility to reach them via VPN. What is your comment on that ?

 

[pilot04]

@Martineau: Thank you for the script. Being a total newbie with firewall rules I am wondering whether your script can also be used to block internet access for various other IoT devices (e.g. smart thermostats, switches, lights etc.)?

I am thinking how to configure my network for home automation devices. Since it is not that easy to set up VLANs with Merlin one option might be to use your script to isolate them from internet and keep the possibility to reach them via VPN. What is your comment on that ?

Yes, that works fine. It is exactly what I used for my LAN. I created multiple ranges ex: .100-.130 for IP cameras, .150-.180 for IoT (smart home, etc ) and assigned DHCP reservations to those devices I need blocked from internet. I can still access the blocked devices via VPN.

 

[Martineau]

@Martineau I am wondering whether your script can also be used to block internet access for various other IoT devices (e.g. smart thermostats, switches, lights etc.)?

Well it depends! ...but as already posted by @pilot04 - YES.

Since it is not that easy to set up VLANs with Merlin one option might be to use your script to isolate them from internet and keep the possibility to reach them via VPN. What is your comment on that ?

I have tinkered with VLANs and created several: 20,30,40,50 and 200
e.g.

./GS108E.sh status

 IoT vlan30 ACTIVE devices (ARP only accurate within 60secs?)
 ===============================================================
10.88.30.18 XX:XX:XX:XX:XX:XX  N/A  (HP-Spectre-X360.martineau.lan)

 Internet vlan40 ACTIVE devices (ARP only accurate within 60secs?)
 =================================================================
10.88.40.15 XX:XX:XX:XX:XX:XX Samsung-TV (?)

 ==================================================================
 VPN (vlan50) br1 ACTIVE devices (ARP only accurate within 60secs?)
 ==================================================================
10.88.101.16 XX:XX:XX:XX:XX:XX N/A  (HP-DM1.martineau.lan)

and Netdata (if installed on the router from entware-ng) can subsequently show separate VLAN activity

e.g. The vlan40 (Internet only) wired TV was playing a Netflix TV show episode, but I attached a wired PC into a different downstream switch's vlan30 (IoT) port and started an .iso download.
NOTE: Previously I also had two Sky+ boxes attached to vlan40, but since I had Sky Q installed, the Sky Q box stubbornly fails to connect to the internet if it 'detects' a vlan!!??.

So for hard wired devices that don't talk to each other this works nicely, but for WiFi IoT devices it can get a little more challenging with opening pin-holes in the firewall etc.

NOTE: Due to changes in v382.xx/v384.xx I have now adopted the use of device-group chains 'Myxxxxxx' to keep the firewall easier to modify (aka debug!)

Spoiler: IPCamsBlock script now uses a chain

Chain MyIPCAMs (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1     3697  281K ACCEPT     udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:123
2     6684  401K DROP       all  --  br0    !tun2+  10.88.8.120          0.0.0.0/0
3      117  7020 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     8363  502K DROP       all  --  br0    !tun2+  10.88.8.123          0.0.0.0/0
6        0     0 DROP       all  --  br0    !tun2+  10.88.8.124          0.0.0.0/0
7     7524  451K DROP       all  --  br0    !tun2+  10.88.8.125          0.0.0.0/0

Spoiler: v384.xx FORWARD chain; referencing my custom chains - much easier on the eye!

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     476K  145M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2    82238 6638K MyIPCAMs   all  --  *      *       0.0.0.0/0            0.0.0.0/0
3    55776 4988K MyVLANs    all  --  *      *       0.0.0.0/0            0.0.0.0/0
4      300 14698 MyAlexa    all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set Alexa src,dst
5        0     0 other2wan  all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0
6     7787  348K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
7       97 10565 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
8    30698 3019K NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0
9        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
10   30698 3019K OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
11   30698 3019K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0

Unlike cameras which only need to legitimately access NTP servers and possibly their home firmware notification sites, I'm not 100% sure of ALL legitimate ports used by IoT devices (such as Alexa) that must not be blocked.

So I have just cloned IPCamsBlock.sh to AlexaBlock.sh and created the following chain:

Chain MyAlexa (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1      236 12993 ACCEPT     tcp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            tcp multiport dports 80,443,8080
2       24  1618 ACCEPT     udp  --  br0    eth0    0.0.0.0/0            8.8.8.8              udp dpt:53
3        0     0 ACCEPT     udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:123
4        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:1900
5        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:4070
6        8   384 ACCEPT     udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:4172
7        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:5353
8        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:35526
9        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:33434
10       0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:40317
11       0     0 logaccept  tcp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            tcp dpt:40317
12       0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:49317
13       0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:50000
14       0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:55495
15       0     0 logaccept  tcp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            tcp dpt:56700
16     924 74643 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADAlexa]"
17     664 60032 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

in order to track which ports (based on Alexa internet ports disclosure) need to be open outbound from any of my listed Alexa devices.

e.g. UDP 4172 is used for Alexa 'calling'

I suggest you implement port tracking for your IoT devices before you impose a Total port block.

NOTE: Whilst it is useful for statistics reporting, rather than have discrete rules for each Alexa-capable device, I simply chose to drop them all into an IPSET which triggers the chain port-tracking.

P.S. Next time you probably won't be so keen to ask for my comments!

 

[HardCat]

Well it depends! ...but as already posted by @pilot04 - YES.

I have tinkered with VLANs and created several: 20,30,40,50 and 200
e.g.

./GS108E.sh status

 IoT vlan30 ACTIVE devices (ARP only accurate within 60secs?)
 ===============================================================
10.88.30.18 XX:XX:XX:XX:XX:XX  N/A  (HP-Spectre-X360.martineau.lan)

 Internet vlan40 ACTIVE devices (ARP only accurate within 60secs?)
 =================================================================
10.88.40.15 XX:XX:XX:XX:XX:XX Samsung-TV (?)

 ==================================================================
 VPN (vlan50) br1 ACTIVE devices (ARP only accurate within 60secs?)
 ==================================================================
10.88.101.16 XX:XX:XX:XX:XX:XX N/A  (HP-DM1.martineau.lan)

and Netdata (if installed on the router from entware-ng) can subsequently show separate VLAN activity

View attachment 11795

e.g. The vlan40 (Internet only) wired TV was playing a Netflix TV show episode, but I attached a wired PC into a different downstream switch's vlan30 (IoT) port and started an .iso download.
NOTE: Previously I also had two Sky+ boxes attached to vlan40, but since I had Sky Q installed, the Sky Q box stubbornly fails to connect to the internet if it 'detects' a vlan!!??.

So for hard wired devices that don't talk to each other this works nicely, but for WiFi IoT devices it can get a little more challenging with opening pin-holes in the firewall etc.

NOTE: Due to changes in v382.xx/v384.xx I have now adopted the use of device-group chains to keep the firewall easier to modify (aka debug!)

Spoiler: IPCamsBlock script now uses a chain

Chain MyIPCAMs (1 references)
num   pkts bytes target     prot opt in     out     source               destination   
1     3697  281K ACCEPT     udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:123
2     6684  401K DROP       all  --  br0    !tun2+  10.88.8.120          0.0.0.0/0     
3      117  7020 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     8363  502K DROP       all  --  br0    !tun2+  10.88.8.123          0.0.0.0/0     
6        0     0 DROP       all  --  br0    !tun2+  10.88.8.124          0.0.0.0/0     
7     7524  451K DROP       all  --  br0    !tun2+  10.88.8.125          0.0.0.0/0

Spoiler: v384.xx FORWARD chain; referencing my custom chains - much easier on the eye!

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination   
1     476K  145M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2    82238 6638K MyIPCAMs   all  --  *      *       0.0.0.0/0            0.0.0.0/0     
3    55776 4988K MyVLANs    all  --  *      *       0.0.0.0/0            0.0.0.0/0     
4      300 14698 MyAlexa    all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set Alexa src,dst
5        0     0 other2wan  all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0     
6     7787  348K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
7       97 10565 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0     
8    30698 3019K NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0     
9        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
10   30698 3019K OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
11   30698 3019K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0

Unlike cameras which only need to legitimately access NTP servers and possibly their home firmware notification sites, I'm not 100% sure of ALL legitimate ports used by IoT devices (such as Alexa) that must not be blocked.

So I have just cloned IPCamsBlock.sh to AlexaBlock.sh and created the following chain:

Chain MyAlexa (1 references)
num   pkts bytes target     prot opt in     out     source               destination   
1      924 74643 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[Alexa]"
2      236 12993 logaccept  tcp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            tcp multiport dports 80,443,8080
3       24  1618 logaccept  udp  --  br0    eth0    0.0.0.0/0            8.8.8.8              udp dpt:53
4        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:123
5        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:1900
6        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:4070
7        8   384 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:4172
8        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:5353
9        0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:35526
10       0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:33434
11       0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:40317
12       0     0 logaccept  tcp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            tcp dpt:40317
13       0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:49317
14       0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:50000
15       0     0 logaccept  udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:55495
16       0     0 logaccept  tcp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            tcp dpt:56700
17     664 60032 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0

in order to track which ports (based on Alexa internet ports disclosure) need to be open outbound from any of my listed Alexa devices.

e.g. UDP 4172 is used for Alexa 'calling'

I suggest you implement port tracking for your IoT devices before you impose a Total port block.

NOTE: Whilst it is useful for statistics reporting, rather than have discrete rules for each Alexa-capable device, I simply chose to drop them all into an IPSET which triggers the chain port-tracking.

P.S. Next time you probably won't be so keen to ask for my comments!

@Martineau - I've been a long time user of IPCamsBlock.sh and would be interested in your newest version. I have also recently picked up an Alexa device and would be interested in AlexBlock.sh too. Any chance you could PM a link? Thanks in Advance. Appreciate the use of your scripts! -HardCat

 

[Martineau]

@Martineau - I've been a long time user of IPCamsBlock.sh and would be interested in your newest version.

The only difference between IPCamsBlock.sh v1.03 and my current v1.05 version is the use of a separate chain and in v1.04 I added (pointless?) tracking of the use of the NTP 123 port.

I have also recently picked up an Alexa device and would be interested in AlexBlock.sh too.

I'm sure you can use other tools to perform the blocking/tracking etc?

However, I have renamed the AlexaBlock.sh script to IoTBlocking.sh and made it generic.

Spoiler: IoTBlocking script help

#======================================================================================== © 2018 Martineau, v1.01b2
#
# Track/Block unsolicited outbound traffic from the IoT devices such as Alexa-capable IPs
#
#     IoTBlock     [-h|help] { 'iot_group' {[ init  | del | status} ] } [ track ] [ noapps] [ report ] [ onerule] [ forcewan ]
#                  [all status]
#
#     IoTBlock     alexa init
#                  IPSET 'Alexa' will be populated with devices from group 'ALEXA' in '/jffs/configs/IPGroups', and Chain 'MyAlexa' will be created
#                  User defined apps firewall rules are added if defined in '/jffs/configs/IoT_Alexa.apps'
#     IoTBlock     alexa del
#                  IPSET 'Alexa' will be flushed, and Chain 'MyAlexa' will be deleted
#     IoTBlock     alexa status
#                  IPSET 'Alexa' will be listed together with Chain statistics
#     IoTBlock     alexa init block
#                  Block ALL i.e. no known ACCEPT rules will be used
#     IoTBlock     alexa report
#                  Scan Syslog for 'BADAlexa' messages and report basic Port/DST/SRC/Protocol statistics.
#                  Then these ports can be added to '/jffs/configs/IoT_Alexa.apps'
#     IoTBlock     all status
#                  All IPSETs will be listed together with Chain statistics
#     IoTBlock     alexa init noapps
#                  No apps rules are added from '/jffs/configs/IoT_Alexa.apps'
#     IoTBlock     alexa init onerule
#                  User defined apps firewall rules are added if defined in '/jffs/configs/IoT_Alexa.apps' only once in the chain; not per device
#     IoTBlock     alexa init forcewan
#                  Replace '-o xxx' -> '-o $WAN_IF' or insert it if not specified.
#
# /jffs/configs/IPGroups
#      ALEXA     Echo-Show,Echo-Dot-KT,Echo-Dot-Guest
#
# /jffs/scripts/firewall-start
#      /jffs/scripts/IoTBlock.sh alexa init
#      /jffs/scripts/IoTBlock.sh lifx init track noapps
#      /jffs/scripts/IoTBlock.sh google init track forcewan

You can now add your vendor (Alexa,Hive,TP-link,Lifx,Nest,Hue,Ring,WeMo,Google,Roku etc.) IoT devices to IoT custom groups in

/jffs/configs/IPGoups

e.g.

ALEXA        Echo_Show,Echo_Bedroom,Echo_Guest
TPLINK       HS110_Lounge1,HS110_Lounge2
LIFX         LIFX_Table,LIFX_Reading
HIVE         Hive_Hub
GOOGLE       Chromecast-Bed1,Chromecast-Bed2
IOT          ALEXA,GOOGLE

To fully BLOCK and track the LIFX devices defined in the 'LIFX' IoT group:

./IoTBlock.sh lifx init

Spoiler: e.g. Blocking Console log

(IoTBlock.sh): 1178 v1.01b IoT Firewall blocking.... lifx init

Name: Lifx
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 212
References: 1
Number of entries: 2
Members:
10.88.8.30 comment "LIFX_Table"
10.88.8.31 comment "LIFX_Reading"

Chain MyLifx (1 references)
num   pkts bytes target     prot opt in     out     source               destination  
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADLifx]"
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
 
(IoTBlock.sh): 17060 IoT (Group Lifx) Firewall Blocking complete.

or to be more lenient, initially allow ALL activity but log it for later analysis

Spoiler: e.g. Tracking Console log

./IoTBlock.sh lifx init track

<snip>

Chain MyLifx (1 references)
num   pkts bytes target     prot opt in     out     source               destination 
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADLifx]"
2        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
   
(IoTBlock.sh): 14500 IoT (Group Lifx) Firewall Tracking complete.

To assist in identifying activity from the Lifx IoT group issue:

./IoTBlock.sh lifx report

(IoTBlock.sh): 5631 v1.01b IoT Firewall blocking.... lifx report

Name: Lifx
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 212
References: 1
Number of entries: 2
Members:
10.88.8.30 comment "LIFX_Table"
10.88.8.31 comment "LIFX_Reading"

Chain MyLifx (1 references)
num   pkts bytes target     prot opt in     out     source               destination 
1        2    88 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADLifx]"
2        2    88 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
 
      1 10.88.8.31 146.148.44.137 TCP SPT=53962 DPT=56700
      1 10.88.8.30 146.148.44.137 TCP SPT=50733 DPT=56700

and you can now opt to whitelist/blacklist the activity by adding the appropriate rules in

/jffs/configs/IoT_Lifx.apps

# IoT group 'Lifx' firewall rules

-A MyLifx -i br0 -p tcp -m tcp --dport 56700 -j ACCEPT

# Alexa uses these
#-A MyAlexa -i br0 -p udp -m udp -m multiport --dports 80,443 -j logaccept
#-A MyAlexa -i br0 -p udp -m udp --dport  4172 -j ACCEPT
etc. see Developer API for a list of ports

so 'init' the Lifx IoT group to have these 'apps' rules added (unless 'noapps' is specified! ;-)
e.g.

Chain MyLifx (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     tcp  --  br0    *       10.88.8.30           0.0.0.0/0            tcp dpt:56700
2        0     0 ACCEPT     tcp  --  br0    *       10.88.8.31           0.0.0.0/0            tcp dpt:56700
3        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADLifx]"
4        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

You may repeat this for your other custom IoT groups...

It might be useful...

 

[HardCat]

The only difference between IPCamsBlock.sh v1.03 and my current v1.05 version is the use of a separate chain and in v1.04 I added (pointless?) tracking of the use of the NTP 123 port.

I'm sure you can use other tools to perform the blocking/tracking etc?

However, I have renamed the AlexaBlock.sh script to IoTBlocking.sh and made it generic.

Spoiler: IoTBlocking script help

#======================================================================================== © 2018 Martineau, v1.01b
#
# Track/Block unsolicited outbound traffic from the IoT devices such as Alexa-capable IPs
#
#     IoTBlock     [-h|help] { 'iot_group' {[ init  | del | status} ] } [ block | track ] [ noapps] [ report ] [ onerule]
#                  [all status]
#
#     IoTBlock     alexa init
#                  IPSET 'Alexa' will be populated with devices from group 'ALEXA' in '/jffs/configs/IPGroups', and Chain 'MyAlexa' will be created
#                  User defined apps firewall rules are added if defined in '/jffs/configs/IoT_Alexa.apps'
#     IoTBlock     alexa del
#                  IPSET 'Alexa' will be flushed, and Chain 'MyAlexa' will be deleted
#     IoTBlock     alexa status
#                  IPSET 'Alexa' will be listed together with Chain statistics
#     IoTBlock     alexa init block
#                  Block ALL i.e. no known ACCEPT rules will be used
#     IoTBlock     alexa report
#                  Scan Syslog for 'BADAlexa' messages and report basic Port/DST/SRC/Protocol statistics.
#                  Then these ports can be added to '/jffs/configs/IoT_Alexa.apps'
#     IoTBlock     all status
#                  All IPSETs will be listed together with Chain statistics
#     IoTBlock     alexa init noapps
#                  No apps rules are added from '/jffs/configs/IoT_Alexa.apps'
#     IoTBlock     alexa init onerule
#                  User defined apps firewall rules are added if defined in '/jffs/configs/IoT_Alexa.apps' only once in the chain; not per device
#
# /jffs/configs/IPGroups
#      ALEXA     Echo-Show,Echo-Dot-KT,Echo-Dot-Guest
#
# /jffs/scripts/firewall-start
#      /jffs/scripts/IoTBlock.sh init alexa
#      /jffs/scripts/IoTBlock.sh init lifx track noapps
#      /jffs/scripts/IoTBlock.sh init google block

You can now add your vendor (Alexa,Hive,TP-link,Lifx,Nest,Hue,Ring,WeMo,Google,Roku etc.) IoT devices to IoT custom groups in

/jffs/configs/IPGoups

e.g.

ALEXA        Echo_Show,Echo_Bedroom,Echo_Guest
TPLINK       HS110_Lounge1,HS110_Lounge2
LIFX         LIFX_Table,LIFX_Reading
HIVE         Hive_Hub
GOOGLE       Chromecast-Bed1,Chromecast-Bed2

To fully BLOCK and track the LIFX devices defined in the 'LIFX' IoT group:

./IoTBlock.sh lifx init

Spoiler: e.g. Blocking Console log

(IoTBlock.sh): 1178 v1.01b IoT Firewall blocking.... lifx init

Name: Lifx
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 212
References: 1
Number of entries: 2
Members:
10.88.8.30 comment "LIFX_Table"
10.88.8.31 comment "LIFX_Reading"

Chain MyLifx (1 references)
num   pkts bytes target     prot opt in     out     source               destination     
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADLifx]"
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0  
 
(IoTBlock.sh): 17060 IoT (Group Lifx) Firewall Blocking complete.

or to be more lenient, initially allow ALL activity but log it for later analysis

Spoiler: e.g. Tracking Console log

./IoTBlock.sh lifx init track

<snip>

Chain MyLifx (1 references)
num   pkts bytes target     prot opt in     out     source               destination    
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADLifx]"
2        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
      
(IoTBlock.sh): 14500 IoT (Group Lifx) Firewall Tracking complete.

To assist in identifying activity from the Lifx IoT group issue:

./IoTBlock.sh lifx report

(IoTBlock.sh): 5631 v1.01b IoT Firewall blocking.... lifx report

Name: Lifx
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 212
References: 1
Number of entries: 2
Members:
10.88.8.30 comment "LIFX_Table"
10.88.8.31 comment "LIFX_Reading"

Chain MyLifx (1 references)
num   pkts bytes target     prot opt in     out     source               destination    
1        2    88 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADLifx]"
2        2    88 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
 
      1 10.88.8.31 146.148.44.137 TCP SPT=53962 DPT=56700
      1 10.88.8.30 146.148.44.137 TCP SPT=50733 DPT=56700

and you can now opt to whitelist/blacklist the activity by adding the appropriate rules in

/jffs/configs/IoT_Lifx.apps

# IoT group 'Lifx' firewall rules

-A MyLifx -i br0 -p tcp -m tcp --dport 56700 -j ACCEPT

# Alexa uses these
#-A MyAlexa -i br0 -p udp -m udp -m multiport --dports 80,443 -j logaccept
#-A MyAlexa -i br0 -p udp -m udp --dport  4172 -j ACCEPT
etc. see Developer API for a list of ports

so 'init' the Lifx IoT group to have these 'apps' rules added (unless 'noapps' is specified! ;-)
e.g.

Chain MyLifx (1 references)
num   pkts bytes target     prot opt in     out     source               destination   
1        0     0 ACCEPT     tcp  --  br0    *       10.88.8.30           0.0.0.0/0            tcp dpt:56700
2        0     0 ACCEPT     tcp  --  br0    *       10.88.8.31           0.0.0.0/0            tcp dpt:56700
3        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADLifx]"
4        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

You may repeat this for your other custom IoT groups...

It might be useful...

@Martineau I noticed in previous post that in the help menu

# /jffs/scripts/firewall-start
#      /jffs/scripts/IoTBlock.sh init alexa
#      /jffs/scripts/IoTBlock.sh init lifx track noapps
#      /jffs/scripts/IoTBlock.sh init google block

the "init" is before "lifx" and in the code snippet after that it is after "lifx". You may want to correct the post to avoid confusion.

 

[JanX]

VPN issues
So, I have read through the thread and I'm using @Martineau IPCamsBlock.sh script (thank you for that) to block my camera from the Internet. The block works fine but I'm having trouble accessing the camera over VPN. No one else has made any complaints so I must be doing something wrong. I hope someone here can point me in the right direction.

What I want to do is use the Eye4 app that comes with VStarCam on my phone. I am connecting though OpenVPN for Android to my Asus router but all I get is "Offline".

I know that the block works because previously I could connect to the camera with the Eye4 app from anywhere (this is the reason I want to block it in the first place).

Status from IPCamsBlock

/jffs/scripts$ ./IPCamsBlock.sh status
[97m
(IPCamsBlock.sh): 2320 v1.04 I/P Cameras Firewall blocking.... status
[91m[93m
num   pkts bytes target     prot opt in     out     source               destination        
4        7   532 ACCEPT     udp  --  br0    eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:123
5      402 26280 DROP       all  --  br0    !tun2+  192.168.2.100        0.0.0.0/0          
[97m
(IPCamsBlock.sh): 2320 I/P Cameras Firewall blocking status request completed.
[0m

iptables -L | grep DROP

/jffs/scripts$ iptables -L | grep DROP
DROP       icmp --  anywhere             anywhere             icmp echo-request
DROP       all  --  anywhere             anywhere             state INVALID
DROP       all  --  anywhere             anywhere           
Chain FORWARD (policy DROP)
DROP       all  --  anywhere             anywhere             MAC 68:FB:7E:41:82:0B
DROP       all  --  VSTARCAM             anywhere           
DROP       all  --  anywhere             anywhere           
DROP       all  --  anywhere             anywhere             state INVALID
DROP       all  --  anywhere             anywhere             state INVALID
DROP       tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,ACK/SYN
DROP       tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,ACK/RST
DROP       icmp --  anywhere             anywhere             icmp echo-request
LOG        all  --  anywhere             anywhere             state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "DROP "
DROP       all  --  anywhere             anywhere

Does anyone have any ideas?

 

[Martineau]

I'm using @Martineau IPCamsBlock.sh script (thank you for that)
The block works fine but I'm having trouble accessing the camera over VPN.

What I want to do is use the Eye4 app that comes with VStarCam on my phone. I am connecting though OpenVPN for Android to my Asus router but all I get is "Offline".

I'm not familiar with the Eye4 App, but have you ruled out DNS/routing issues?

i.e. Try defining the remote camera by IP address in the phone's Eye4 App, and (temporarily) force all traffic via the OpenVPN tunnel from your phone.

P.S.

iptables -L | grep DROP

DROP       all  --  anywhere             anywhere             MAC 68:FB:7E:41:82:0B
DROP       all  --  VSTARCAM             anywhere

is not very informative, I suggest you use

iptables -nvL --line | grep DROP

when debugging iptables.

 

[Zentachi]

iptables -nvL --line | grep DROP

when debugging iptables.

I also cannot access the two IPCams via VPN and I know that I missed something, even though I have read the thread at least three times to find the bit I missed.
Using version 1.04 of your script.

Here is my iptables

Chain FORWARD (policy DROP 0 packets, 0 bytes)
4        0     0 DROP       all  --  eth0   *       0.0.0.0/0            192.168.2.50         state NEW
5     3225  203K DROP       all  --  br0    !tun2+  192.168.2.50         0.0.0.0/0
6        0     0 DROP       all  --  eth0   *       0.0.0.0/0            192.168.2.51         state NEW
7      232 16181 DROP       all  --  br0    !tun2+  192.168.2.51         0.0.0.0/0

Shouldn't tun2+ be ACCEPT?


PS: If you release the IoTBlock script at some point would be awesome.

 

[Martineau]

I also cannot access the two IPCams via VPN and I know that I missed something, even though I have read the thread at least three times to find the bit I missed.
Using version 1.04 of your script.

Shouldn't tun2+ be ACCEPT?

The 'DROP !tun2+' rule means

"ANY outbound traffic from either 192.168.2.50 or 192.168.2.51 that isn't routed via a VPN Server tunnel is DROP'd'"

You could try

./IPCamsBlock.sh   init   logdrop

./IPCamsBlock.sh   status

iptables -nvL FORWARD --line

and you should now be able to see why the outbound camera traffic is being DROP'd, and there should be no DROP messages containing 'OUT=tun2' from either 192.168.2.50 or 192.168.2.51.

 

[Zentachi]

The 'DROP !tun2+' rule means

"ANY outbound traffic from either 192.168.2.50 or 192.168.2.51 that isn't routed via a VPN Server tunnel is DROP'd'"

You could try

./IPCamsBlock.sh   init   logdrop

./IPCamsBlock.sh   status

iptables -nvL FORWARD --line

and you should now be able to see why the outbound camera traffic is being DROP'd, and there should be no DROP messages containing 'OUT=tun2' from either 192.168.2.50 or 192.168.2.51.

Only DROP's I can see are 'DROP IN=br0 OUT=eth0'. Nothing about tun2.

In case it helps:
I switched off the internet and captured the connections in my android phone while I was connecting to the camera. One app was connected to 10.0.0.1 and the other app to 203.205.128.130.
I have two different cameras each with each one app.

 

[Martineau]

Only DROP's I can see are 'DROP IN=br0 OUT=eth0'. Nothing about tun2.

In case it helps:
I switched off the internet and captured the connections in my android phone while I was connecting to the camera. One app was connected to 10.0.0.1 and the other app to 203.205.128.130.
I have two different cameras each with each one app.

I would review the software listed in your signature.

Good luck.

 

[Zentachi]

I would review the software listed in your signature.

Good luck.

Disabled all scripts beside the cam blocking but no luck.

Anyways, I will keep experimenting and might get to the root of the problem.
Thanks.

 

[KroetKroet]

Hello @Martineau
I have been playing around with vlans to "secure" my IP camera stuff on AC87U, however without success. But I now found your gem!
I understand the splitting up between camera->internet and inbound VPN-only. However, I'm having a trust issue with my camera's being on my plain LAN (eg. if camera injects stuff on my NAS for example). That's why I went for vlans in the first place but did not succeed.

So basically, what I would like to achieve, is that on top of your outbound&inbound WAN, but opened VPN access, I'd like to have a block on OUTBOUND camera-> LAN, yet allowed INBOUND LAN -> camera. The latter is already available, but the first not.

Do you think that would be a nice addition to your script?

I'm guessing it's something like
iptables -I FORWARD 2 -s 192.168.222.98 -o eth0 -j DROP
But when I add this manually to my router, he still let me ping out from the camera IP towards my LAN.

Thanks for your support!

 

[Martineau]

Hello @Martineau
I have been playing around with vlans to "secure" my IP camera stuff on AC87U, however without success.

VLANs would be the ideal solution although you may need additional VLAN capable switches for preferred hard-wired IP/Cameras etc. NOT sure why your foray into VLANs failed?

However, I'm having a trust issue with my camera's being on my plain LAN (eg. if camera injects stuff on my NAS for example).

Surely you would use the firewall on the NAS to block inbound access?

So basically, what I would like to achieve, is that on top of your outbound&inbound WAN, but opened VPN access, I'd like to have a block on OUTBOUND camera-> LAN, yet allowed INBOUND LAN -> camera.

LAN-LAN device traffic doesn't use router firewall rules as they are processed by the switch.

However, you could put the IP cameras on a Guest SSID, and set up an admin pin-hole access port from a specified LAN device, but I did play with a script

Spoiler: BlockWiFiClient

VER="01.01"
#======================================================================================================= © 2016-2017 Martineau, v1.01
#
# Allow blocking of standard Wifi devices (non-Guest) from accessing LAN/WAN resources.
#
# BlockWiFiClient [help | -h] | [status [full] | ['from_ip' ['to_ip' | lan | wan] ] [accept] [del]
# [ {'config_file'} [del] ]
# BlockWiFiClient 10.88.8.155 10.88.8.197
# Wifi Client 10.88.8.155 will be BLOCKED from accessing 10.88.8.197
# BlockWiFiClient 10.88.8.155 del
# All blocking rules for WIfi Client 10.88.8.155 will be deleted
# BlockWiFiClient 10.88.8.155 lan
# Wifi Client 10.88.8.155 will be BLOCKED from accessing LAN (10.88.8.0/24)
# BlockWiFiClient 10.88.8.155 wan
# Wifi Client 10.88.8.155 will be BLOCKED from accessing the (Internet) WAN
# BlockWiFiClient Nexus-7 DS-416
# WiFI Nexus-7 Client (10.88.8.155) will be BLOCKED from accessing DS-416 (NAS 10.88.8.197) - LAN or WiFI
# BlockWiFiClient Nexus-7 DS-416 accept
# WiFI Nexus-7 Client (10.88.8.155) ALL LAN access will be BLOCKED except for access to DS-416 (NAS 10.88.8.197)
# i.e. ALL previous BLOCK rules for this WiFi Client are deleted
# BlockWiFiClient Nexus-7 DS-416 accept del
# WiFI Nexus-7 Client (10.88.8.155) will be allowed access to DS-416 (NAS 10.88.8.197) unless the LAN BLOCK rule still exists.
# BlockWiFiClient Nexus-7 lan
# WiFI Nexus-7 Client (10.88.8.155) will be BLOCKED from accessing anything on the LAN
# BlockWiFiClient Nexus-7 del
# WiFI Nexus-7 Client (10.88.8.155) will be allowed access to LAN/WAN (all rules deleted for this WiFI Client)
# BlockWiFiClient
# will show status of the 'logical' rules
# BlockWiFiClient status
# will show status of the relevant ebtables rules (use 'status full' for full ebtable -t broute BROUTING chain)
# BlockWiFiClient /jffs/config/Nexus-7
# All Peer to Peer DROP/ACCEPT rules are to be read from the file and applied to WiFi Client Nexus-7
# BlockWiFiClient /jffs/config/Nexus-7 del
# All blocking rules for WiFI Nexus-7 Client (10.88.8.155) will be deleted.
#
# NOTE: The name of the file is assumed to be the HOSTNAME of the WiFi Client.
#
# Format of config directives: (DROP/ACCEPT cannnot be used concurrently - comment either out with #)
#
# e.g. # Peer rules
# DROP DS-416
# DROP 10.88.8.120-10.88.8.125,RaspberryPiB
#
# or
#
# ACCEPT CAMERAS
#
# For the ACCEPT rule, a LAN subnet BLOCKING (DROP) rule is automatically added and the exception ACCEPT rules are then inserted,
# and ALL BLOCK rules below the LAN Blocking rule are deleted!
# Custom IP Groups may be defined/referenced in '/jffs/configs/IPGroups'
# e.g. 'CAMERAS' entry (Uppercase text!)
# CAMERAS 10.88.8.10,10.88.8.15-10.88.8.20,10.88.8.50:10.88.8.55[/CODE]

that may be a possible solution for your specific edge-case requirement.

 

[KroetKroet]

@Martineau : Thanks for your quick reply!
1) regarding the VLANs: I tried the script from @Arnie Singh in this topic: https://www.snbforums.com/threads/f...asus-merlin-rt-ac68u.18969/page-3#post-390301:
in short: my AC87U with IPTV on LAN4 (port1) had following vlans OOTB:

vlan1: 2 3 5 7t
vlan2: 0 1 7

So I added 101 on port 3 (which is LAN2) where my NVR is going to be deployed. I've plugged in a standard pc, with fixed IP 192.168.222.98.
What happened is this:

1: vlan1: 2 5t 7t
2: vlan2: 0 1 7
101: vlan101: 3 7t

Port 5 changed to 5Tagged which is odd, and not requested/intented. And even worse: my LAN & wifi devices cannot connect to vlan 101 or vice versa, but my vlan 101 can connect to the internet (which was not the objective at all, it should be revered). (eg ping from 192.168.222.100 to .98 fails, but from 98 to .1 and .100 succeeds)
So I'm not sure whether I'd need an extra vlan capable switch down the road, with 1 pc plugged into (in my case) LAN port 2, that should be vlan-nable within the AC87U, right
2) regarding firewall on NAS: good solution, but what about other IoT devices that I doesn't want my NVR/Ip camera's talk with. You can't block them all.
3) good solution, although if my NVR/camera's would be wifi, that would be a good alternative, but here I'm aiming for "LAN" separation. And from what I understood: vlans is way to go, with on top ebtables filtering on top of iptables filtering.

Thanks!!!

 

[Martineau]

Port 5 changed to 5Tagged which is odd, and not requested/intented.

There are several posts regarding the inaccuracy of the robocfg utility e.g. see Help understanding vlan port configuration RT-AC87U

I'm not sure whether I'd need an extra vlan capable switch down the road, with 1 pc plugged into (in my case) LAN port 2, that should be vlan-nable within the AC87U, right

Using VLAN capable switches certainly makes VLAN tagging for isolating Ethernet LAN devices makes life so much easier.

 

[KroetKroet]

There are several posts regarding the inaccuracy of the robocfg utility e.g. see Help understanding vlan port configuration RT-AC87U


Using VLAN capable switches certainly makes VLAN tagging for isolating Ethernet LAN devices makes life so much easier.

Thanks @Martineau ! Indeed, I figured out the port 5 and 7 are the "special" ports on the AC87U.

It has been a long time ago since I played with my Cisco CCNP/CCNA stuff, but I'm not following you on the advantage of using a VLAN Capable switch: In that case, I would make eg port 3 tagged on the AC87U, and untag it at the other switch and patch cameras/NVR in. However, my WAN would need to strip only that vlan off port 0. Which makes it impossible for connecting from LAN to the CCTV Vlan, unless all LAN devices need to VPN through WAN-OpenVPN and hop-off into the CCTV Vlan.
I found another interesting article on how to put a fixed IP on the LAN port interface, and work through the routing table and "fix"/"block" traffic accordingly. But that would be lots of trial and error lol.
Thank you and have a nice day!