TP-Link 的 NTP 流量

在「TP-Link repeater firmware squanders 715 MB/month」這邊看到 TP-Link 因為 NTP 的關係而狂吃流量的情況:(這邊是用逗點表示小數點,所以是 715.4 MB/month)

You should probably avoid TP-Link products if you’re on a tight bandwidth budget. By design, TP-Link firmware sends six DNS requests and one NTP query every 5 seconds, for a total of 715,4 MB per month.

如果拿 24 小時都開機的 Windows 相比的話,會發現這數字天差地別:

To put this number in context: an always-on Windows device will use around 1,6 KB per month on NTP.

作者抓出韌體上面的設定,發現裡面寫死了不少伺服器... 那個 aunz 的選擇讓人頗好奇,另外直接把幾個大學的 NTP server 放進去不知道是什麼樣的想法:

TP-Link has hardcoded the following non-configurable NTP servers and server pools in their firmware:


The first sets of servers are operated by the US National Institute of Standards and Technology (NIST). The second is the Australian and New Zealand public NTP project time server pools. The IP addresses are owned by universities in Japan, Colorado; US, and Sweden respectively.

而從行為可以看到沒有遵守這些 NTP service 的規範:

The NTP Pool project asks device manufacturers and vendors to register (and optionally sponsor) their own pools through the service (e.g., and emphasize that they “must absolutely not use the default zone names”. They also request that vendors don’t check more often than every 5 minutes at the most.

而且因為沒有地方可以修改這些設定,唯一的解法是不要買 TP-Link 的產品:

You can avoid buying TP-Link products to avoid this problem.

You can’t turn this behavior off in TP-Link’s web administration interface nor in their management app for mobile. You can’t change the NTP server addresses it targets either.

AWS 環境裡面提供 NTP Service 了 (Amazon Time Sync Service)

以前在 AWS 環境裡都要自己架設兩台可以連外的 NTP server,然後將內部機器指到這兩台上,現在可以用現成的了:「Keeping Time With Amazon Time Sync Service」。


You can access the service via the link local IP address. This means you don’t need to configure external internet access and the service can be securely accessed from within your private subnets.

然後也有提到 leap second 的解法,用的解法是 leap smearing:

Leap seconds are known to cause application errors and this can be a concern for many savvy developers and systems administrators. The clock smooths out leap seconds some period of time (commonly called leap smearing) which makes it easy for your applications to deal with leap seconds.

先前 AWS 也有 leap time,但不包括 Amazon EC2 這些系統 (EC2 裡的時間是獨立的),不過還是可以看一下 AWS 處理 leap time 的方式,因為這次 NTP Service 就會拿去用了。

最近一次 leap time 是 2016 年底的「Look Before You Leap – December 31, 2016 Leap Second on AWS」,處理的方式跟 2015 年時的方法還是一樣:「Look Before You Leap – The Coming Leap Second and AWS (Updated)」。



This service is provided at no additional charge and is immediately available in all public AWS regions to all instances running in a VPC.

微軟的 Time Service 回應錯誤的時間...

看起來會有不少災情 (像是 SQL Server 遇到使用 server side 的時間的 SQL query):「Windows Time Service is sending out wrong times and that’s a big problem」,報導裡引用了 Reddit 上「PSA: NTP server seems to be sending out wrong time」這邊的討論串。

為了避免這種情況,不同單位會用不同方法解決。像是財力充足的 Google 就自己搞了原子鐘,然後還放 Google Public NTP 出來給大家用。可以不倚靠外部裝置確保自家時間的正確性。

另外是有人用 Raspberry Pi 收 GPS 訊號轉成 NTP service (像是「The Raspberry Pi as a Stratum-1 NTP Server」這邊介紹的方式),不過之前有發生過 GPS 送出來的時間差了 13ms 的事情,也不是完全可靠 (不過相較起來應該還是可以接受):「GPS error caused '12 hours of problems' for companies」。另外可能的方案有 GLONASS (俄羅斯的系統)。


Google 的

看到這張圖在講不同 server (service) 如何處理今年的 leap second (UTC 的跨年,台灣時間早上八點),出自 leap smear 這邊:

在很早前就有 這個 domain,但是當時 Google 的人有跳出來說明這個服務不是公開服務 (當時),不保證這個服務的正確性與穩定性:「 provide non standard time」。

不過一個月前公佈出來的 Google Public NTP 服務算是把整個系統搞定了。

其中在 Configuring Clients 這邊直接推薦用 iburst 參數,不愧是家大業大的 Google XDDD:

When the server is unreachable and at each poll interval, send a burst of eight packets instead of the usual one. As long as the server is unreachable, the spacing between packets is about 16s to allow a modem call to complete. Once the server is reachable, the spacing between packets is about 2s. This is designed to speed the initial synchronization acquisition with the server command and s addresses and when ntpd is started with the -q option.

回到原來的 leap smear 的比較圖,可以看出 Google 對 leap second 的解法是往前十二小時與往後十二小時各拉緩衝時間來避開,有些是沒在管,另外有些有種來亂的感覺 XDDD

Apple 首次自動強制更新:NTP 安全問題

Apple 第一次的自動強制更新就給了這次的 ntpd 安全性問題 CVE-2014-9295:「Apple pushes first ever automated security update to Mac users」。

A remote unauthenticated attacker may craft special packets that trigger buffer overflows in the ntpd functions crypto_recv() (when using autokey authentication), ctl_putdata(), and configure(). The resulting buffer overflows may be exploited to allow arbitrary malicious code to be executed with the privilege of the ntpd process.


最近的 NTP attack 的檢測...

最近幾天 NTP 放大攻擊還蠻嚴重的,像是 CloudFlare 這兩天就被 400Gbps 貓:「NTP-based DDoS attacks a concern, says Cloudflare」。

CloudFlare 有寫過一篇 NTP 放大攻擊的說明:「Understanding and mitigating NTP-based DDoS attacks」。

另外在 irc 上看到系上學弟說可以查詢有哪些 NTP server 是會被當作 NTP 放大攻擊的工具:「 - NTP Scanning Project」,把 IP range 丟進去就可以看到 (一次可以查到 /22),可以當作一份外部資訊來幫助內部優先處理。

NTP server 放大攻擊的防治...

一樣是在 Zite 上看到的,有人提到對 NTP server 的放大攻擊:「Re: Public ntp-server and reflection-attacks」。

攻擊者送一個封包,就會產生約 100 個封包的回應... (於是就被放大了)

This means, the attacker sends _one_ packet and gets _100_ packets to his target.

像是這樣的指令就會傳回很多資訊:(剛好也學到 ntpdc 這個指令...)

gslin@colo-p [~] [04:18/W4] ntpdc -c monlist
remote address          port local address      count m ver code avgint  lstint
localhost              36284 ::1               443425 7 2      0     27       0           123      7891 4 4      0   1027     197     123      7821 4 4      0   1024     838
59-124-196-84.HINET-IP   123      7856 4 4      0   1024     920


restrict default noquery nomodify notrap nopeer
restrict -6 default noquery nomodify notrap nopeer