What TLS traffic did 384.5 introduced towards asuscloud.com on TCP port 5601 ?

[develox]

Hi to all,

since updating to 384.5 on my RT-AC5300 I've got my peripheral ZyWALL logging denied outbound traffic from the RT-AC5300 WAN IP towards IPs belonging to asuscloud.com. Suricata logs them as follows (e.g.):

TLS: TLS 1.2 - aae-sgweb886-vx.asuscloud.com - C=TW, L=New Taipei City, O=ASUS Cloud Corporation, CN=*.asuscloud.com

Note, I've no Asus Cloud service enabled except AiProtection and that's been working so far with opening rules I've setup over time on the ZyWALL.

Anyone knows what is this about ?

BR
Peppe

 

[RMerlin]

Probably tied to their NAT tunnelling technology, used for instance for AiCloud.

Try disabling NAT Tunelling on the Tools -> Other Settings page to see if it helps.

Unfortunately I don't have any more info, these services are all closed source.

 

[develox]

Thanks for getting into this Eric. Unfortunately it doesn't seem to be it. I've head a look at the logs this morning: the traffic is quite frequent. I count 1062 hits since May 17 16:07:38. It's about one transmission per minute on average (I've let the traffic through for the night so this should be the intended steady state with no retries).

 

[RMerlin]

Check if you have either aaews or mastiff processes running. It's probably caused by one of these two.

 

[develox]

Check if you have either aaews or mastiff processes running. It's probably caused by one of these two.

Thanks again Eric. I have both:

ahdmin@RT-AC5300-50C0:/tmp/home/root# ps | egrep "aaews|mastiff"
  435 ahdmin   5192 S    mastiff
  459 ahdmin   5192 S    mastiff
  460 ahdmin   5192 S    mastiff
19095 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19098 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19110 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19115 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19116 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19117 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19118 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
20500 ahdmin   9228 S    aaews --sdk_log_dir=/tmp

though: I've no idea what they are && I can't find trace of them in any log file && aaews_log under /tmp has zero size.

Are they mapped into some user's discretionary function in the GUI or script accessible via busybox ? Can they be enabled/disabled if needed/unneeded ?

 

[RMerlin]

Thanks again Eric. I have both:

ahdmin@RT-AC5300-50C0:/tmp/home/root# ps | egrep "aaews|mastiff"
  435 ahdmin   5192 S    mastiff
  459 ahdmin   5192 S    mastiff
  460 ahdmin   5192 S    mastiff
19095 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19098 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19110 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19115 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19116 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19117 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
19118 ahdmin   9228 S    aaews --sdk_log_dir=/tmp
20500 ahdmin   9228 S    aaews --sdk_log_dir=/tmp

though: I've no idea what they are && I can't find trace of them in any log file && aaews_log under /tmp has zero size.

Are they mapped into some user's discretionary function in the GUI or script accessible via busybox ? Can they be enabled/disabled if needed/unneeded ?

Those services are started by the firmware. There's currently no way for end-users to disable these. The Tweaks setting was added to at least partially allow disabling them, but it's possible that other closed source portions of the firmware can also launch them.

 

[develox]

Thanks again Eric. It'd be interesting to know what's their purpose. I made a try at blocking them and they got mad: this morning I found over 11K packet drop notices since just midnight (more than 1K attempts per hour). As I see the updates over Trend Micro proceed with no troubles on their path and as I left the check for th WAN via DNS probes (and disabled Nat tunnelling as suggested), I wonder what does the router needs to talk with Asus' cloud so intensely about.

Sent from my ONEPLUS A3003 using Tapatalk