Menu
What's new
By:
Filters
Better Search

Help Please..Need assistance stopping outbound connections!

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

OK, results as follows and time was updated accordingly using 172.16.1.1

Code: 
hardcat@RT-AC86U:/tmp/home/root# iptables -t nat -nvL PREROUTING --line-numbers
Chain PREROUTING (policy ACCEPT 263 packets, 46068 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        1    76 DNAT       udp  --  br0    *       192.168.xxx.101      0.0.0.0/0            udp dpt:123 /* Laptop */ to:192.168.xxx.1
2      122  9272 DNAT       udp  --  br0    *       192.168.xxx.140/31   0.0.0.0/0            udp dpt:123 /* Wemo */ to:192.168.xxx.1
3      315 67253 VSERVER    all  --  *      *       0.0.0.0/0            xxx.xxx.xxx.198
 
HardCat said:
OK, results as follows and time was updated accordingly using 172.16.1.1

Code: 
hardcat@RT-AC86U:/tmp/home/root# iptables -t nat -nvL PREROUTING --line-numbers
Chain PREROUTING (policy ACCEPT 263 packets, 46068 bytes)
num   pkts bytes target     prot opt in     out     source               destination    
1        1    76 DNAT       udp  --  br0    *       192.168.xxx.101      0.0.0.0/0            udp dpt:123 /* Laptop */ to:192.168.xxx.1
2      122  9272 DNAT       udp  --  br0    *       192.168.xxx.140/31   0.0.0.0/0            udp dpt:123 /* Wemo */ to:192.168.xxx.1
3      315 67253 VSERVER    all  --  *      *       0.0.0.0/0            xxx.xxx.xxx.198
Click to expand...
Brilliant :)

I've formally added the feature to v1.02b
Code: 
./IoTBlock.sh    wemo    init    localntp=10.88.8.1

(IoTBlock.sh): 2530 v1.02b IoT Firewall blocking.... wemo init localntp=10.88.8.1

<snip>

 IoT rules:

Chain MyWemo (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 "[BADWemo]"
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
    
 NTP redirect rules:

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination     
1        0     0 DNAT       udp  --  br0    *       192.168.111.123      0.0.0.0/0            udp dpt:123 /* Wemo */ to:10.88.8.1

(IoTBlock.sh): 2530 IoT (Group Wemo) Firewall Blocking complete.
 
Last edited:
Martineau said:
Brilliant :)

I've formally added the feature to v1.02b
Code: 
./IoTBlock.sh    wemo    init    localntp=10.88.8.1

(IoTBlock.sh): 2530 v1.02b IoT Firewall blocking.... wemo init localntp=10.88.8.1

<snip>

 IoT rules:

Chain MyWemo (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 "[BADWemo]"
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
   
 NTP redirect rules:

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination    
1        0     0 DNAT       udp  --  br0    *       192.168.111.123      0.0.0.0/0            udp dpt:123 /* Wemo */ to:10.88.8.1

(IoTBlock.sh): 2530 IoT (Group Wemo) Firewall Blocking complete.
Click to expand...
Will there be a link to the new version when it is ready? I would like to use it.:)
 
HardCat said:
Will there be a link to the new version when it is ready? I would like to use it.:)
Click to expand...

Ha ha! :p .. v1.01 posted on Feb 1 2018 has expired!
 
Martineau said:
Ha ha! :p .. v1.01 posted on Feb 1 2018 has expired!
Click to expand...
New version v1.02 up and running! After a reboot of the router...
Code: 
Oct 29 18:17:27 (IoTBlock.sh): 2165 v1.02b IoT Firewall blocking.... WeMo init localntp=192.168.xxx.1
Oct 29 18:17:27 (IoTBlock.sh): 2165 Apps firewall rules (1) read from '/jffs/configs/IoT_Wemo.apps' Success=1
Oct 29 18:17:28 (IoTBlock.sh): 2165 IoT (Group Wemo) Firewall Blocking complete.
and...
Code: 
hardcat@RT-AC86U:/jffs/scripts# ./IoTBlock.sh status

(IoTBlock.sh): 4517 v1.02b IoT Firewall blocking.... status


Name: Wemo
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 339
References: 1
Number of entries: 2
192.168.xxx.140    192.168.xxx.141   

    Total=2



Name: WemoTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 96
References: 0
Number of entries: 0


    Total=0


    IoT rules:

Chain MyWemo (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        1   188 ACCEPT     tcp  --  br0    *       192.168.xxx.140      0.0.0.0/0            tcp multiport dports 3475,3478,8443
2        1   188 ACCEPT     tcp  --  br0    *       192.168.xxx.141      0.0.0.0/0            tcp multiport dports 3475,3478,8443
3        1    76 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADWemo]"
4        1    76 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

    NTP redirect rules:

Chain PREROUTING (policy ACCEPT 1074 packets, 262K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        1    76 DNAT       udp  --  br0    *       192.168.xxx.141      0.0.0.0/0            udp dpt:123 /* Wemo */ to:192.168.xxx.1

I did notice the first device 192.168.xxx.140 got caught up, most likely a timing issue. I will check what starts where in the firewall and post-mount scripts.
Code: 
Oct 29 18:29:33 kernel: [BADWemo]IN=br0 OUT=eth0 MAC=b0:6e:xx:xx:xx:xx:xx:75:0e:xx:xx:xx:xx:xx SRC=192.168.xxx.140 DST=192.5.41.41 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=51510 DF PROTO=UDP SPT=123 DPT=123 LEN=56
This is great stuff! Thank You...:)
 
Merlin n00b (long-time DD-WRT and Linux/UNIX user) here with a shiny new RT-AC86U as my main router. I don't see any *firewall* scripts anywhere in the latest version, so where should I add the call to /jffs/scripts/IPCamsBlock.sh ?

Okay, created /jffs/scripts/firewall-start with the single line /jffs/scripts/IPCamsBlock.sh init and looks like it executed on a reboot/startup sequence. Sorry to ask the st00pid question.
 
Last edited:
Martineau said:
Ha ha! :p .. v1.01 posted on Feb 1 2018 has expired!
Click to expand...
@Martineau , this morning I tested a bit more manually. First I executed the delete function, then I checked that with the status function to confirm the deletion. Next, I manually executed:
Code: 
hardcat@RT-AC86U:/jffs/scripts# ./IoTBlock.sh WeMo init localntp=192.168.xxx.1

(IoTBlock.sh): 5359 v1.02b IoT Firewall blocking.... WeMo init localntp=192.168.xxx.1


    Apps firewall rules (1) read from '/jffs/configs/IoT_Wemo.apps' Success=1


Name: Wemo
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 339
References: 1
Number of entries: 2
Members:
192.168.xxx.141 comment "LS-Office"
192.168.xxx.140 comment "LS-Porch"


Name: WemoTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 96
References: 0
Number of entries: 0


    Total=0


    IoT rules:

Chain MyWemo (1 references)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.140      0.0.0.0/0            tcp multiport dports 3475,3478,8443
2        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.141      0.0.0.0/0            tcp multiport dports 3475,3478,8443
3        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADWemo]"
4        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0          

    NTP redirect rules:

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination        

(IoTBlock.sh): 5359 IoT (Group Wemo) Firewall Blocking complete.

hardcat@RT-AC86U:/jffs/scripts#
Notice nothing is displayed in Chain PREROUTING, however if I run the status command again, the second device is there...:confused:
Code: 
hardcat@RT-AC86U:/jffs/scripts# ./IoTBlock.sh status

(IoTBlock.sh): 5894 v1.02b IoT Firewall blocking.... status


Name: Wemo
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 339
References: 1
Number of entries: 2
192.168.xxx.140    192.168.xxx.141  

    Total=2



Name: WemoTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 96
References: 0
Number of entries: 0


    Total=0


    IoT rules:

Chain MyWemo (1 references)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.140      0.0.0.0/0            tcp multiport dports 3475,3478,8443
2        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.141      0.0.0.0/0            tcp multiport dports 3475,3478,8443
3        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADWemo]"
4        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0          

    NTP redirect rules:

Chain PREROUTING (policy ACCEPT 687 packets, 205K bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        1    76 DNAT       udp  --  br0    *       192.168.xxx.141      0.0.0.0/0            udp dpt:123 /* Wemo */ to:192.168.xxx.1
 
Last edited:
HardCat said:
@Martineau , this morning I tested a bit more manually. First I executed the delete function, then I checked that with the status function to confirm the deletion. Next, I manually executed:
Code: 
hardcat@RT-AC86U:/jffs/scripts# ./IoTBlock.sh WeMo init localntp=192.168.xxx.1

(IoTBlock.sh): 5359 v1.02b IoT Firewall blocking.... WeMo init localntp=192.168.xxx.1


    Apps firewall rules (1) read from '/jffs/configs/IoT_Wemo.apps' Success=1


Name: Wemo
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 339
References: 1
Number of entries: 2
Members:
192.168.xxx.141 comment "LS-Office"
192.168.xxx.140 comment "LS-Porch"


Name: WemoTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 96
References: 0
Number of entries: 0


    Total=0


    IoT rules:

Chain MyWemo (1 references)
num   pkts bytes target     prot opt in     out     source               destination  
1        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.140      0.0.0.0/0            tcp multiport dports 3475,3478,8443
2        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.141      0.0.0.0/0            tcp multiport dports 3475,3478,8443
3        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADWemo]"
4        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0    

    NTP redirect rules:

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination  

(IoTBlock.sh): 5359 IoT (Group Wemo) Firewall Blocking complete.

hardcat@RT-AC86U:/jffs/scripts#
Notice nothing is displayed in Chain PREROUTING, however if I run the status command again, the second device is there...:confused:
Code: 
hardcat@RT-AC86U:/jffs/scripts# ./IoTBlock.sh status

(IoTBlock.sh): 5894 v1.02b IoT Firewall blocking.... status


Name: Wemo
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 339
References: 1
Number of entries: 2
192.168.xxx.140    192.168.xxx.141

    Total=2



Name: WemoTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 96
References: 0
Number of entries: 0


    Total=0


    IoT rules:

Chain MyWemo (1 references)
num   pkts bytes target     prot opt in     out     source               destination  
1        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.140      0.0.0.0/0            tcp multiport dports 3475,3478,8443
2        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.141      0.0.0.0/0            tcp multiport dports 3475,3478,8443
3        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADWemo]"
4        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0    

    NTP redirect rules:

Chain PREROUTING (policy ACCEPT 687 packets, 205K bytes)
num   pkts bytes target     prot opt in     out     source               destination  
1        1    76 DNAT       udp  --  br0    *       192.168.xxx.141      0.0.0.0/0            udp dpt:123 /* Wemo */ to:192.168.xxx.1
Click to expand...


I would dump the RT-AC86U - despite its performance specs there are seemingly still far too many undesired quirks? :p but all joking aside, in the script clearly there are only two possible calls to display the iptables rules:
Code: 
1. When the 'init' directive is used
2. When the 'status' directive is used.

Show_Status $IOT_GROUP "IPSET"
I honestly can't recreate your 'display' issue (on non-RT-AC86U hardware) but I have posted v1.02b1 which if you could please try I would be grateful (or you can dump my shoddy script. :p)
 
Last edited:
Martineau said:
I would dump the RT-AC86U - despite its performance specs there are seemingly still far too many undesired quirks? :p but all joking aside, in the script clearly there are only two possible calls to display the iptables rules:
Code: 
1. When the 'init' directive is used
2. When the 'status' directive is used.

Show_Status $IOT_GROUP "IPSET"
I honestly can't recreate your 'display' issue (on non-RT-AC86U hardware) but I have posted v1.02b1 which if you could please try I would be grateful (or you can dump my shoddy script. :p)
Click to expand...
Tested, looks good for the features I have tested so far. No need to dump anything!:( Now I will add my Alexa device and a few other toys I have up my sleeve...Many thanks!:D
PS. I am very happy with my RT-AC86U and have not come across any limitations in my network as of yet.
 
H
Martineau said:
I would dump the RT-AC86U - despite its performance specs there are seemingly still far too many undesired quirks? :p but all joking aside, in the script clearly there are only two possible calls to display the iptables rules:
Code: 
1. When the 'init' directive is used
2. When the 'status' directive is used.

Show_Status $IOT_GROUP "IPSET"
I honestly can't recreate your 'display' issue (on non-RT-AC86U hardware) but I have posted v1.02b1 which if you could please try I would be grateful (or you can dump my shoddy script. :p)
Click to expand...


Hi Martineau
Would love to try out your V1.02b1 IOT script on my RT-AC5300. I have a multitude of Alexa devices and sems a perfect fit for my requirements. Thank you,
 
joe scian said:
Hi Martineau
Would love to try out your V1.02b1 IOT script on my RT-AC5300. I have a multitude of Alexa devices and sems a perfect fit for my requirements. Thank you,
Click to expand...

Woah... are you mad :eek:, taking a big risk with yet another one of my shoddy scripts? :p

PM'd you the link.;)
 
Martineau said:
Woah... are you mad :eek:, taking a big risk with yet another one of my shoddy scripts? :p

PM'd you the link.;)
Click to expand...

You forget that your shoddy is most persons absolutely brilliant!!
 
Hi Martineau

I dont think the script is finding my Alexa devices - Is it because its changing the CASE to Uppercase?

In my wireless log the 2 names appear as below

amazon-06802718a
amazon-c16dc9d27

however in wireless View list homepage i changed the names of the two devices to

amazon-jens den
amazon-Main

my IPGROUPS is as follows:-
CAMERAS 192.168.2.73
ALEXA amazon-06802718a,amazon-c16dc9d27,amazon-jens den,amazon-Main

(iotblock.sh): 22192 v1.02b1 IoT Firewall blocking.... ALEXA init
(iotblock.sh): 22192 Lookup 'AMAZON-06802718A' in '/jffs/configs/IPGroups' returned:><
(iotblock.sh): 22192 Lookup 'AMAZON-C16DC9D27' in '/jffs/configs/IPGroups' returned:><
(iotblock.sh): 22192 Lookup 'AMAZON-JENS' in '/jffs/configs/IPGroups' returned:><
(iotblock.sh): 22192 Lookup 'DEN' in '/jffs/configs/IPGroups' returned:><
(iotblock.sh): 22192 Lookup 'AMAZON-MAIN' in '/jffs/configs/IPGroups' returned:><
Name: Alexa
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 60
References: 1
Number of entries: 0
Members:
Name: AlexaTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 60
References: 0
Number of entries: 0
Total=0
IoT rules:
Chain MyAlexa (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:123
2 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 7 level 4 prefix "[BADAlexa]"
3 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
(iotblock.sh): 22192 IoT (Group Alexa) Firewall Blocking complete.
 
joe scian said:
Hi Martineau

I dont think the script is finding my Alexa devices - Is it because its changing the CASE to Uppercase?

In my wireless log the 2 names appear as below

amazon-06802718a
amazon-c16dc9d27

however in wireless View list homepage i changed the names of the two devices to

amazon-jens den
amazon-Main

my IPGROUPS is as follows:-
CAMERAS 192.168.2.73
ALEXA amazon-06802718a,amazon-c16dc9d27,amazon-jens den,amazon-Main

(iotblock.sh): 22192 v1.02b1 IoT Firewall blocking.... ALEXA init
(iotblock.sh): 22192 Lookup 'AMAZON-06802718A' in '/jffs/configs/IPGroups' returned:><
(iotblock.sh): 22192 Lookup 'AMAZON-C16DC9D27' in '/jffs/configs/IPGroups' returned:><
(iotblock.sh): 22192 Lookup 'AMAZON-JENS' in '/jffs/configs/IPGroups' returned:><
(iotblock.sh): 22192 Lookup 'DEN' in '/jffs/configs/IPGroups' returned:><
(iotblock.sh): 22192 Lookup 'AMAZON-MAIN' in '/jffs/configs/IPGroups' returned:><
Click to expand...

For each 'item'

1. Ping the 'item'
2. Look for the 'item' in '/etc/dnsmasq.conf' (in case it is reserved but offline)

If both FAIL, then indeed, as per the original IPCamsBlock.sh script, the 'item' is then assumed to be a group name, converted to upper-case and '/jffs/configs/IPGroups' is then scanned for a possible group match to be expanded.

If the presumed group is not defined then it generates the 'undefined group' message as shown above.

I suggest you try defining the group 'ALEXA' containing only IP addresses, to see what 'names' are added to the IPSET.
 
Martineau said:
For each 'item'

1. Ping the 'item'
2. Look for the 'item' in '/etc/dnsmasq.conf' (in case it is reserved but offline)

If both FAIL, then indeed, as per the original IPCamsBlock.sh script, the 'item' is then assumed to be a group name, converted to upper-case and '/jffs/configs/IPGroups' is then scanned for a possible group match to be expanded.

If the presumed group is not defined then it generates the 'undefined group' message as shown above.

I suggest you try defining the group 'ALEXA' containing only IP addresses, to see what 'names' are added to the IPSET.
Click to expand...


Thanks - will do - unfortunately going to have to wait till next week as i cant reach my router anymore - im in a remote loc and an MTU change has made my router and network unreachable. Cheers
 
(iotblock.sh): 19598 v1.02b1 IoT Firewall blocking.... alexa status
Name: Alexa
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 293
References: 1
Number of entries: 3
Members:
192.168.2.245 comment "192.168.2.245"
192.168.2.47 comment "192.168.2.47"
192.168.2.133 comment "192.168.2.133"
Name: AlexaTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 60
References: 0
Number of entries: 0
Total=0
IoT rules:
Chain MyAlexa (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:123
2 132 7764 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 7 level 4 prefix "[BADAlexa]"
3 132 7764 DROP all -- * * 0.0.0.0/0 0.0.0.0/0


Hi Martineau
I had to manually update /etc/dnsmasq.conf with the three IP addresses and MAC addresses. For some reason the two ALexa Echo Dot devices and Echo Plus are not pingable and therefore do not appear in /etc/dnsmasq
 
Does the status look right to you?

Hi Martineau
I had to manually update /etc/dnsmasq.conf with the three IP addresses and MAC addresses of the three Alexa devices. For some reason the two ALexa Echo Dot devices and Echo Plus are not pingable on my network and therefore do not appear in /etc/dnsmasq.conf or hosts.dnsmasq

Does the status look right to you? Certainly seems to be working well with lots of BADAlexa outbound blocks in log
 
Last edited:
joe scian said:
Does the status look right to you? Certainly seems to be working well with lots of BADAlexa outbound blocks in log
Click to expand...
Well it depends.:p
joe scian said:
I had to manually update /etc/dnsmasq.conf with the three IP addresses and MAC addresses of the three Alexa devices.
For some reason the two ALexa Echo Dot devices and Echo Plus are not pingable on my network and therefore do not appear in /etc/dnsmasq.conf or hosts.dnsmasq
Click to expand...
Hmm, no idea why your Alexa devices apparently do not respond to PING? My Alexas have always been PINGable and are obviously assigned Reserved IPs in the DHCP Server GUI so they automatically get added to /etc/dnsmasq.conf.

So, besides having defined 'Alexa' application rules in
/jffs/configs/IoT_Alexa_apps
e.g.
Code: 
# Alexa "calling"
-A MyAlexa -i br0  -p udp -m udp --dport 4172 -j ACCEPT -m comment --comment Voice-Calling
I currently still use passive tracking for my Alexa IoT Group
/jffs/scripts/nat-start
Code: 
Say "IoT device Blocking/Tracking requested....."
/jffs/scripts/IoTBlock.sh alexa  init track onerule
rather than totally blocking the '[BADAlexa]' traffic

NOTE: I updated the firmware late yesterday evening, so my stats reflect only a few hours of (quiet) overnight activity (but I just attempted a video call but immediately hung-up just to trigger Port 4172 ;)) ....but weird that there appears to be hard-coded 192.168.0.* requests despite my LAN/VLANs being 10.88.*.*o_O perhaps during the firmware update reboots I may have inadvertently reset my LAN subnet:confused:

Code: 
./IoTBlock.sh   alexa   report

(IoTBlock.sh): 20846 v1.02b2 IoT Firewall blocking.... alexa report

Name: Alexa
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 435
References: 1
Number of entries: 5
Members:
10.88.8.19 comment "Echo_Guest"
10.88.8.18 comment "Echo_Spot"
10.88.8.16 comment "Echo_Show"
10.88.8.17 comment "Echo_Kitchen"
10.88.8.32 comment "Echo_Spare"

Name: AlexaTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 60
References: 0
Number of entries: 0

 Total=0

 IoT rules:

Chain MyAlexa (1 references)
num   pkts bytes target     prot opt in     out     source               destination   
1        0     0 ACCEPT     udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:123
2     4448  268K ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 80,443,8080
3        1    67 ACCEPT     udp  --  br0    *       0.0.0.0/0            8.8.8.8              udp dpt:53
4        0     0 logaccept  udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:1900
5        0     0 logaccept  udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:4070
6       11   552 ACCEPT     udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:4172 /* Voice-Calling */
7        0     0 logaccept  udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:5353
8        0     0 logaccept  udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:35526
9        0     0 logaccept  udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:33434
10       0     0 logaccept  udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:40317
11       0     0 logaccept  tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:40317
12       0     0 logaccept  udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:49317
13       0     0 logaccept  udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:50000
14       0     0 logaccept  udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:55495
15       0     0 ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:50686
16       0     0 ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:56700
17       0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADAlexa]"
18       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

   
      1 164.52.24.175 wan.xxx.xxx.xxx TCP SPT=33586 DPT=2455
      1 10.88.8.16 84.93.94.88 UDP SPT=57544 DPT=48966
      1 10.88.8.16 52.30.222.137 UDP SPT=36531 DPT=56650
      1 10.88.8.16 34.247.66.2 UDP SPT=57544 DPT=53267
      1 10.88.8.16 2.221.183.239 UDP SPT=36531 DPT=56650
      1 10.88.8.16 2.221.183.239 UDP SPT=36531 DPT=34781
     15 10.88.8.16 192.168.0.4 UDP SPT=36531 DPT=34781
      2 10.88.8.16 192.168.0.3 TCP SPT=55973 DPT=33956
      2 10.88.8.16 192.168.0.3 TCP SPT=49680 DPT=33956
      2 10.88.8.16 192.168.0.3 TCP SPT=40136 DPT=33956
      2 10.88.8.16 192.168.0.3 TCP SPT=38328 DPT=33956
      1 10.88.8.16 192.168.0.3 TCP SPT=33710 DPT=33956
      1 10.88.8.16 10.99.8.233 UDP SPT=57544 DPT=48966

Unknown TCP/UDP Ports
Name: AlexaTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 60
References: 0
Number of entries: 0
Members:
      1 164.52.24.175 wan.xxx.xxx.xxx TCP SPT=33586 DPT=2455

EDIT Fix typo. All APP rule files begin 'IoT' :oops: - Thanks @joe scian
 
Last edited:
yes - I have no idea why they are not pingable - got me stumped -
BTW - i saw this in my log as well - any ideas?
20:15:07 (IPCamsBlock.sh): 24105 v1.09 I/P Cameras Firewall blocking.... init mail logdrop
Nov 13 20:15:07 (IPCamsBlock.sh): 24105 ***ERROR Intrinsic 'iptables -t filter logdrop' chain functionality has been purposely CRIPPLED by ACTIVE SKynet...WTF?!!!
 
joe scian said:
yes - I have no idea why they are not pingable - got me stumped -
BTW - i saw this in my log as well - any ideas?
20:15:07 (IPCamsBlock.sh): 24105 v1.09 I/P Cameras Firewall blocking.... init mail logdrop
Nov 13 20:15:07 (IPCamsBlock.sh): 24105 ***ERROR Intrinsic 'iptables -t filter logdrop' chain functionality has been purposely CRIPPLED by ACTIVE SKynet...WTF?!!!
Click to expand...

There are inherent ASUS implemented firewall rules that refer to '-j logdrop'
Code: 
iptables-save | grep -E "logdrop"

:logdrop - [0:0]
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -j logdrop
-A INPUT -m state --state INVALID -j logdrop
-A INPUT -j logdrop

-A FORWARD -m state --state INVALID -j logdrop

-A NSFW -i br0 -o eth0 -j logdrop

-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j logdrop
-A SECURITY -p icmp -m icmp --icmp-type 8 -j logdrop

-A logdrop -j DROP

-A other2wan -j logdrop
so presumably in the SECURITY chain (and if the USER enables Network Services Filter) etc. then ASUS deems it a requirement to write a tracking message to Syslog rather than silently DROP the packet.

When Skynet is installed, this expected logging functionality is no longer available - no idea why Skynet now wishes to interfere and unilaterally prevent firewall rule trigger messages being written to Syslog? :rolleyes:
(NOTE: Even if you temporarily disable Skynet, it doesn't restore the logdrop chain.)

P.S. You can provide the 'fixskynet' directive when requesting IPCamsBlock.sh and both the script and the ASUS firewall rules will work as intended.
 
You must log in or register to reply here.

Similar threads

bengalih
Need help with OpenVPN server configured in non-routing mode
Replies
1
Views
854
bengalih
bengalih
N
[Need Help Plz] RT-AX86U not picking up WAN IP from XB7
Replies
7
Views
1K
L&LD
L&LD
D
When connected to my GT-AX6000 something is not allowing certain apps or functions to work on our phones and I need help how to troubleshoot
2
Replies
30
Views
3K
dyer4789
D
K
Issues with dual router setup
Replies
5
Views
2K
Tech9
Tech9
M
Asus RT-AX89X How to add A firewall blacklist composed of Stretchoid scanners
Replies
0
Views
2K
majika
M
Similar threads
Thread starter Title Forum Replies Date
el_pedr0 Please help me diagnose knotty routing problem Asuswrt-Merlin 4
H Virgin FTTP and ASUS AXE16000 problems…… please help. Asuswrt-Merlin 6
A Help Required Upgrading AC68U from Stock FW to Merlin Please? Asuswrt-Merlin 15
F ASUS RT-AC86U (merlin Current Version : 386.12_6): jffs2: Argh. No free space left for GC. Can you help me troubleshoot this please? Asuswrt-Merlin 6
J Help Please Upgrade Time Asuswrt-Merlin 4
T [Help] Problems setting up OpenVPN Asuswrt-Merlin 7
staralfur12 Need help with Namecheap -> Router -> Caddy Asuswrt-Merlin 10
P Asus aimesh node disconnects frequently, corresponding log entries recorded. Need help understanding the log. Asuswrt-Merlin 5
V Asus RT-AX3000 Help Asuswrt-Merlin 5
StrikerXXX Need help configuring NextDNS Asuswrt-Merlin 14

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Total: 870 (members: 28, guests: 842)
Top