小村軟體有限公司
第 4 章

2008 年的教訓 — 並行查詢與短期對策

把 2008 年廣為人知的問題,理解為高層次的攻擊思路與短期對策。

前章回顧: 第 3 章中,我們整理了回應接受條件 (question / ID / address / port)、race window,以及 entropy 與嘗試次數的關係。本章將以該框架為基礎,確認 2008 年廣為人知的問題「為何嚴重」,以及自當時延續至今的短期對策組合。

注意: 本章談的是歷史教訓與防禦上的意圖,不會處理實際環境的攻擊步驟或 exploit code。

2008 年的嚴重之處

DNS cache poisoning 本身很早就被知道了,但 2008 年由 Dan Kaminsky 廣為周知的問題 (一般稱為「Kaminsky 攻擊」) 讓一個要點變得更鮮明:「只要能不斷製造 uncached 的查詢機會,就算 race window 很短,attempts 仍然可以被增加。」本章不討論詳細攻擊步驟,但若以高層次的思路來說,概念是「對 random123.example.com 之類不存在的標籤接連發出查詢,每次都製造 fresh miss,並進行多次 race 嘗試」。

即使一次 race 很短,只要 fresh miss 不斷被製造,累積的危險就會增加。RFC 5452 之所以把 attempts 與 outstanding queries 分開說明,就是為了讓讀者掌握這個圖像。

fresh miss
cache 裡沒有的查詢越多,新的 race window 就越多。
identical outstanding queries
同一個查詢並行開得越多,同一個 window 裡任一個被猜中的機率就越高。
shared cache
一次錯誤的接受就會波及全體使用者。

練習 4-1 — attempts 被增加為何是嚴重問題

即使一次 race 很短,只要 fresh miss 不斷被製造,累積的危險就會增加。

Q1. 2008 年廣為人知的 DNS cache poisoning 問題,最接近的教訓是哪一個?

關鍵在「是什麼把嘗試次數增加了」。

Q2. 其他條件不變,只把 identical outstanding queries 的數量 D 從 1 增加到 2 這樣的小範圍,1 個 window 的 spoof 成功機率大致會怎麼變?

RFC 5452 說明在 D 很小時可以近似看成比例關係。

open recursion 與監控

如同練習 4-1 所示,推升危險的最大要因是「attempts (fresh miss 的發生次數)」。那麼,誰能增加這個 attempts?其中一個答案是 open recursion。當 resolver 任何人都能使用時,第三者就能從外部自由地發起 query,結果便容易刻意推升 fresh miss 與 attempts。也就是說,open recursion 是一種「為攻擊者拓寬 attempts 增加之入口」的構成。

這等於在負載、觀測雜訊、race opportunity 三方面都擴大了 exposure。在維運上,把「對隨機 label 的 query 爆增」「特定 zone 的 miss 偏多」「NAT 造成的 port entropy 劣化」等放進監控指標,比較容易察覺行為的變化。

練習 4-2 — open recursion 與短期對策

任何人都能讓 resolver 發起 query 的狀態會擴大 exposure。僅靠單一面向的短期對策並不足夠。

Q3. 就 cache poisoning 的角度而言,open recursion 最容易提高風險的原因最接近哪個?

想想「誰能引發 query」這個入口的寬窄。

Q4. 下列哪一項不屬於短期對策?

想想看哪一項副作用大、做為防禦又不夠。

Q5. 下列哪一項是錯誤的?

回想一下 DNSSEC 是「用簽章做驗證」還是「保密」。

第 4 章重點整理

  • 即使 race window 很短,只要 fresh miss 與 attempts 被推高,危險就會累積
  • open recursion 會擴大 exposure,所以基本做法是限制給 trusted clients
  • patch / entropy / recursion control / 監控是短期 hardening 的基本盤