Help Please..Need assistance stopping outbound connections!

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

HardCat

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

Code:
[email protected]:/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
 

Martineau

Part of the Furniture
OK, results as follows and time was updated accordingly using 172.16.1.1

Code:
[email protected]:/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
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:

HardCat

Regular Contributor
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.
Will there be a link to the new version when it is ready? I would like to use it.:)
 

Martineau

Part of the Furniture
Will there be a link to the new version when it is ready? I would like to use it.:)

Ha ha! :p .. v1.01 posted on Feb 1 2018 has expired!
 

HardCat

Regular Contributor
Ha ha! :p .. v1.01 posted on Feb 1 2018 has expired!
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:
[email protected]:/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...:)
 

FredTheFrog

Occasional Visitor
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:

HardCat

Regular Contributor
Ha ha! :p .. v1.01 posted on Feb 1 2018 has expired!
@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:
[email protected]:/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.

[email protected]:/jffs/scripts#
Notice nothing is displayed in Chain PREROUTING, however if I run the status command again, the second device is there...:confused:
Code:
[email protected]:/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:

Martineau

Part of the Furniture
@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:
[email protected]:/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.

[email protected]:/jffs/scripts#
Notice nothing is displayed in Chain PREROUTING, however if I run the status command again, the second device is there...:confused:
Code:
[email protected]:/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


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:

HardCat

Regular Contributor
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)
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.
 

joe scian

Very Senior Member
H
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)


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,
 

Martineau

Part of the Furniture
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,

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

PM'd you the link.;)
 

joe scian

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

PM'd you the link.;)

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

joe scian

Very Senior Member
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.
 

Martineau

Part of the Furniture
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:><

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.
 

joe scian

Very Senior Member
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.


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
 

joe scian

Very Senior Member
(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
 

joe scian

Very Senior Member
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:

Martineau

Part of the Furniture
Does the status look right to you? Certainly seems to be working well with lots of BADAlexa outbound blocks in log
Well it depends.:p
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
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:

joe scian

Very Senior Member
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?!!!
 

Martineau

Part of the Furniture
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?!!!

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.
 

Latest threads

Sign Up For SNBForums Daily Digest

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