Network Time Security 正式成為 IETF 標準

在「NTS is now an RFC」這邊看到 Network Time Security 成為 IETF 的標準了:「Network Time Security for the Network Time Protocol」。

這個標準比較特別的是,因為 TLS 裡對 certificate 的驗證需要先有正確的時間,而導致 NTP 直接套用 TLS 會有「先有雞還是先有蛋」這樣的問題出現。這點在「8.5. Initial Verification of Server Certificates」這個章節裡面被討論到:

However, the expectation that the client does not yet have a correctly-set system clock at the time of certificate verification presents difficulties with verifying that the certificate is within its validity period, i.e., that the current time lies between the times specified in the certificate's notBefore and notAfter fields.

看起來還是頗複雜,但至少先給個方法出來了...

Facebook 提供 Public NTP Service

在「Building a more accurate time service at Facebook scale」這邊 Facebook 講了不少跟 NTP 有關的東西,不過重點在他們提供 Public NTP service:

Having five independent geographically distributed endpoints helps us provide better service — even in the event of a network path failure. So we provide five endpoints:

  • time1.facebook.com
  • time2.facebook.com
  • time3.facebook.com
  • time4.facebook.com
  • time5.facebook.com

Each of these endpoints terminates in a different geographic location, which has a positive effect on both reliability and time precision.

看起來是混了 anycast 進去,從台灣 (HiNet) 走的話,time1.facebook.com 會到東京,time2.facebook.com 到大阪 (難得在 traceroute 上看到 ITM 這個代碼,代表 伊丹機場),time3.facebook.com 則是台灣,time4.facebook.com 到香港,time5.facebook.com 好像是馬來西亞?看 latency 與 maa 這個詞... (Update:應該是清奈國際機場)

可以考慮看看,另外 Google Public NTP 也是個選項。

Cloudflare 弄了 time.cloudflare.com,不過 latency 沒有很好...

Cloudflare 提供的 NTP service,使用 time.cloudflare.com:「Introducing time.cloudflare.com」。

官方是號稱所有的機房 (應該就包括台北的點):

Now, anyone can get time securely from all our datacenters in 180 cities around the world.

但在 HiNet 下測試可以看到是從東京的點服務:

  2.|-- snuh-3302.hinet.net        0.0%    10    9.5  10.5   9.5  12.7   0.8
  3.|-- tpdt-3022.hinet.net        0.0%    10   11.1  10.8  10.1  11.8   0.3
  4.|-- r4103-s2.tp.hinet.net      0.0%    10   27.2  11.9   9.3  27.2   5.4
  5.|-- r4003-s2.tp.hinet.net      0.0%    10   11.3  10.7   9.5  11.6   0.3
  6.|-- xe-0-0-0-3-6.r02.osakjp02  0.0%    10   47.9  48.7  47.6  49.9   0.6
  7.|-- ae-2.a00.osakjp02.jp.bb.g  0.0%    10   44.9  47.3  42.8  66.4   6.9
  8.|-- ae-20.r03.osakjp02.jp.bb.  0.0%    10   43.7  43.2  42.5  44.7   0.3
  9.|-- 61.120.144.46              0.0%    10   69.6  52.4  48.0  69.6   6.8
 10.|-- 162.159.200.123            0.0%    10   48.3  48.8  47.9  49.3   0.0

如果從 APOL (有線電視) 的點則是透過台灣的機房連線:

  3.|-- 10.251.11.6                0.0%    10   19.8  29.6  11.1  80.2  21.7
  4.|-- 10.251.231.5               0.0%    10   25.3  24.9  16.4  43.6   8.0
  5.|-- 10.251.231.1               0.0%    10    8.7   6.3   3.4   9.1   1.9
  6.|-- 10.251.230.34              0.0%    10    4.6   7.4   2.6  14.5   3.2
  7.|-- 10.251.230.29              0.0%    10    3.0   6.6   3.0  11.9   2.8
  8.|-- 202-178-245-162.cm.static  0.0%    10    4.8   7.3   4.8   9.9   1.4
  9.|-- 192.168.100.14             0.0%    10    7.3   8.0   5.4  11.1   2.0
 10.|-- 192.168.100.9              0.0%    10    8.2   8.0   4.9  11.1   1.7
 11.|-- 203-79-250-65.static.apol  0.0%    10    9.1   9.0   6.4  11.3   1.5
 12.|-- 211.76.96.92               0.0%    10    7.8   8.1   4.3  15.8   3.3
 13.|-- 39-222-163-203-static.tpi  0.0%    10    9.9   9.1   6.7  12.4   1.8
 14.|-- 162.159.200.1              0.0%    10    5.0   7.2   5.0   9.7   1.4

看起來又是有東西沒搞定了...

針對 Ubuntu 16.04 + PPPoE 時,OpenNTPD 的 -s 不會在啟動時直接校正的問題 workaround...

發現機器時間跟標準時間差了 40 秒左右,結果有些服務因為會看雙方時間,就不讓我跑... XDDD

找問題找了半天,發現開機後 ntpdate 會回報找不到伺服器,看起來是網路根本就還沒通就跑起來了:

Jan 25 13:10:30 home ntpdate[757]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1171]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1347]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1410]: name server cannot be used: Temporary failure in name resolution (-3)

而理論上 與 openntpd 加上 -s 也會做類似的事情,所以這邊就在 /etc/default/openntpd 先加上 -s,讓他開機時強制對時一次,看看能不能解... 結果也是一樣在網路還沒通的時候就跑起來而失敗了:

Jan 25 13:10:45 home ntpd[1457]: no reply received in time, skipping initial time setting

由於這台機器是 HiNet 的 PPPoE,看起來有可能是某些條件沒寫好,造成執行順序不對... 所以就找個 workaround 來解決 @_@

後來找的方法是直接到 /etc/ppp/ip-up.d/ 下放一個 script 實作 workaround,直接在 PPPoE 連上後重跑 openntpd,然後用 hwclock 寫回主機裡,下次開機的時間就會比較準一些了:

#!/bin/sh -e

/usr/sbin/service openntpd restart
/sbin/hwclock -w

不過實際上還是要找看看要怎麼把 PPPoE 掛到 networking 那層行為裡面...

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:

  • time.nist.gov, time-a.nist.gov, time-b.nist.gov, time-nw.nist.gov
  • au.pool.ntp.org, nz.pool.ntp.org
  • 133.100.9.2, 128.138.140.44, 192.36.144.22

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. tplink.pool.ntp.org), and emphasize that they “must absolutely not use the default pool.ntp.org 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」。

服務放在 169.254.169.123

You can access the service via the link local 169.254.169.123 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 169.254.169.123 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: time.windows.com 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 的 time.google.com

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

在很早前就有 time.google.com 這個 domain,但是當時 Google 的人有跳出來說明這個服務不是公開服務 (當時),不保證這個服務的正確性與穩定性:「timeX.google.com 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 放大攻擊的工具:「OpenNTPProject.org - NTP Scanning Project」,把 IP range 丟進去就可以看到 (一次可以查到 /22),可以當作一份外部資訊來幫助內部優先處理。