Solved Intercepting NTP traffic Philips Hue Hub

[BreakingDad]

I have noticed through my dns logs that my philips hub sends time requests to ntp1.aliyun.com and ntp2.aliyun.com for it's time updates.

These are ali babas time servers, based in China.

The reason Philips say that these time servers are used on their devices are because of the great wall of china, the devices may not work on google ntps etc.

They seem to be hardcoded into the hub, and no matter what I do with intercept in Merlin, or intercept in ntpMerlin, or putting on local time server, changing them etc, they still go out to China.

Is there anyway around this, as I would prefer not to send anything to China, even if it is only a time request.

This is lazy non regional firmware imo.

Here is a reddit thread about the same issue from someone else Reddit

Look forward to your comments.

 

[SomeWhereOverTheRainBow]

I have noticed through my dns logs that my philips hub sends time requests to ntp1.aliyun.com and ntp2.aliyun.com for it's time updates.

These are ali babas time servers, based in China.

The reason Philips say that these time servers are used on their devices are because of the great wall of china, the devices may not work on google ntps etc.

They seem to be hardcoded into the hub, and no matter what I do with intercept in Merlin, or intercept in ntpMerlin, or putting on local time server, changing them etc, they still go out to China.

Is there anyway around this, as I would prefer not to send anything to China, even if it is only a time request.

This is lazy non regional firmware imo.

Here is a reddit thread about the same issue from someone else Reddit

Look forward to your comments.

First, if you could please share any data you may have collected including Wireshark packet inspections, dns query logs, or any other relevant data that serves as adequate indication that ntp is not being properly intercepted by iptable rules. Next thing to also consider doing is to attempt blocking these domains at the DNS level as well, since some devices can fall back to ntp lookup over traditional dns. The final thing that might need to be considered is blocking the China ip addresses at the firewall level.

Remember how using blockers and firewalls typically unintentionally breaks things, this may be one of those instances where they may fix them by doing what they are good at - breaking things.

 

[BreakingDad]

First, if you could please share any data you may have collected including Wireshark packet inspections, dns query logs, or any other relevant data that serves as adequate indication that ntp is not being properly intercepted by iptable rules. Next thing to also consider doing is to attempt blocking these domains at the DNS level as well, since some devices can fall back to ntp lookup over traditional dns. The final thing that might need to be considered is blocking the China ip addresses at the firewall level.

Here are the adguard logs, I tried blocking ntp1.aliyum with adguard, and yes it blocks it, but it does not go out to another ntp server as far as I can tell

China is already blocked on skynet, but the hub seems to bypass all instruction from the router.

Taking a look at wireshark.

 

[SomeWhereOverTheRainBow]

Here are the adguard logs, I tried blocking ntp1.aliyum with adguard, and yes it blocks it, but it does not go out to another ntp server as far as I can tell


View attachment 44264

China is already blocked on skynet, but the hub seems to bypass all instruction from the router.

Try blocking the domains via dns blocklisting to see how behaviors change. You probably won't see the requested address change here in the dns query log, ultimately you need a tool like Wireshark to inspect a packet. It at that level show the request interception and replies from the forced ntp addresses.


Here is an example of packet inspection I did back in the day to verify stubby DoT encryption was working.

Tutorial - [ DoT Study ] ######MBM DoT Study#######

I want to first of all thank my Loyal followings of #Nobody. Here is another @SomeWhereOverTheRainBow thread-cast #my-first-one-ever List of things needed. Asuswrt-Merlin(384.12 and up preferred) or with DoT entware setup putty (SSH client) entware tcp-dump wireshark Okay so this is a guide...

www.snbforums.com

You can also use these methods to verify whether or not ntp redirection is working. It would literally show you that the request is being forced to someplace else if redirection is truly working. The things you don't see in the query log. Please note you may have to do alittle additional leg work on determining the proper dump command to capture the ntp packet however tcpdump should be cable of doing the necessary capture.

 

[Crimliar]

Okay, genuine question... When we have a redirection in place at the router, in order to see that redirection has taken place, wouldn't we need to study packets either on the WAN interface or use say System Log > Connections ? Internal capture is surely just going to show the original destination and not the re-routing!

 

[SomeWhereOverTheRainBow]

Okay, genuine question... When we have a redirection in place at the router, in order to see that redirection has taken place, wouldn't we need to study packets either on the WAN interface or use say System Log > Connections ? Internal capture is surely just going to show the original destination and not the re-routing!

To answer your question, the way I am suggesting to inspect it is literally as the router intercepts it not as the client request it. What we would expect to see is the clients request ,but the actual return interception response coming from a different address. The same type of inspections can be done with intercepted DNS.

 

[XIII]

I have noticed through my dns logs that my philips hub sends time requests to ntp1.aliyun.com and ntp2.aliyun.com for it's time updates.

Interesting! (I was not aware of this)

In my NextDNS logs I see a single request to each of ntp1, ntp2, ntp3, and ntp4 for that domain (so 4 requests in total) in August plus a single request to ntp1 (only) in September.

Still 5 requests too much…

How frequent do they appear in your log?

 

[BreakingDad]

To answer your question, the way I am suggesting to inspect it is literally as the router intercepts it not as the client request it. What we would expect to see is the clients request ,but the actual return interception response coming from a different address. The same type of inspections can be done with intercepted DNS.

Therefore the inteception, may be occuring, it's just that I cannot see it in the original dns request, as that only shows the client request and not the interception, whereas wireshark should pick up the interception ?

 

[BreakingDad]

Still 5 requests too much…

I get one every 10 min or so.

 

[SomeWhereOverTheRainBow]

Therefore the inteception, may be occuring, it's just that I cannot see it in the original dns request, as that only shows the client request and not the interception, whereas wireshark should pick up the interception ?

Wireshark should show the actual information on where the response to the request came from as well as long as the packet capture of traffic is being inspected at the router level. The place where the interception takes place.

 

[BreakingDad]

at the router level.

So that would mean running it on the router?

 

[SomeWhereOverTheRainBow]

So that would mean running it on the router?

Doing it via the ssh terminal logged into the router using tools from entware repo. You would dump the information to a pcap file that you can export via scp to a computer to look at with wireshark.

 

[BreakingDad]

Doing it via the ssh terminal logged into the router using tools from entware repo. You would dump the information to a pcap file that you can export via scp to a computer to look at with wireshark.

wow, a job for when the brain is fully working. I added ntp blocks to skynet. it is still querying the ips tho. I might just poke up with it. The world has not ended as yet.

 

[SomeWhereOverTheRainBow]

wow, a job for when the brain is fully working. I added ntp blocks to skynet. it is still querying the ips tho. I might just poke up with it. The world has not ended as yet.

I will do some work on it later for you if you would like. It will require some work at my workstation later in the evening. For me, it is 7am right now, so I am still burning the morning oil. Hopefully later today I should have some screen shots of what you would hope to see.

 

[BreakingDad]

I will do some work on it later for you if you would like. It will require some work at my workstation later in the evening. For me, it is 7am right now, so I am still burning the morning oil. Hopefully later today I should have some screen shots of what you would hope to see.

Thank you for your help, no rush at all, appreciate the help, hope it's not too far over my head. I have to take my daughter to dance right now so don't want to get into anything too complex.

 

[dave14305]

Sounds like you just don’t like seeing the queries in your DNS logs, which is a completely different issue than whether NTP intercept is working (it will be working fine for all IPv4 ntp requests).

 

[BreakingDad]

Sounds like you just don’t like seeing the queries in your DNS logs, which is a completely different issue than whether NTP intercept is working (it will be working fine for all IPv4 ntp requests).

You're not wrong; I don't like seeing the hue querying a chinese ntp when I live in the uk. I don't like it being hardcoded into the most recent firmware (I also have issues with google devices having hardcoded 8.8.8.8 but that's another story).

I thought, it seems wrongly, that the intercept would show it going to the ntp of my choice. Even if I block it on skynet it still shows the query. Again perhaps it is not going anywhere after the query. I guess it goes to adguard first. Then gets blocked (or intercepted).

There's an idea for a new plugin for you or someone else smart, one that shows the intercepts in action. Perhaps an addition to ntpMerlin.

There is a difference for me at least, of seeing it working, and just hoping it is working.

 

[bluepoint]

You will know if the NTP intercepts are working when you see UDP 123 requests from your philips hue IP's to your router's address in syslog\connections, no need to over analyze it.

 

[dave14305]

It looks like Merlin’s NTP intercept wouldn’t catch NTP traffic on Guest Network #1 (interfaces br1, br2) because it only looks at br0. Yet another reason to avoid Guest Network #1.

https://github.com/RMerl/asuswrt-merlin.ng/blob/021766bdf95a792f4e6c62cfb00f7fa608c9bc56/release/src/router/rc/firewall.c#L1757

 

[BreakingDad]

You will know if the NTP intercepts are working when you see UDP 123 requests from your philips hue IP's to your router's address in syslog\connections, no need to over analyze it.

Thank you, I had to wait along time of refreshing to see it but got there in the end.

udp

192.168.1.30

33850

192.168.1.1

123

We have success.

Interestingly it seems that skynet was indeed blocking the ntp requests with the locale block cn anyway. I've checked a load of ntp requests today and they're mostly going out to uk, or google etc.

I've learnt quite a lot as well with this experiement and the help from you guys.

device-dns request- intercept-firewall-internet-time server-firewall-device, something like that anyway.

Happy now that the intercepts are working as expected.