誰在掃描我家的 IPv6 地址？首次發現對內網主機真實IPv6地址的精準掃描

文/宋崟川

宋崟川先生是美國領英（LinkedIn）的工程師，也是“IPv6 產業生態圈”和“IPv6 頭跳讀者群”活躍的技術型群友之一。他維護的網站https://IPv6-CN.com 向廣大朋友提供原創和翻譯的 IPv6 資料。

宋崟川先生的家庭網絡已經接入了 IPv6帶寬。9 月 20 日宋先生在微信群里通報：家中路由器的防火墻日志顯示 9 月份有三次（截至本文發稿時有六次）來自 AWS 云主機對家庭內網主機 IPv6 地址80 端口的精準掃描。

以下是事件發生的經過，以及宋崟川先生對攻擊事件的深度分析。

在 IPv4 環境下，對 TCP 和 UDP 的端口掃描非常常見，而且攻擊者經常掃描整個網絡的所有地址。這種肆無忌憚的掃描每分鐘可能有幾十或上百次。

到了 IPv6 的時代，IPv6 一個子網的大小就是整個 IPv4 地址數量的 232倍，非常不利于攻擊者掃描目標網絡。通常我們認為在IPv6上對網段的掃描不會發生，起碼對于了解 IPv6 的攻擊者來說不會選擇這樣浪費時間。

然而在本文的例子中，我們看到了針對家庭寬帶用戶的單個 IPv6 地址的單一端口掃描，為什么會發生這樣的事情呢？我們作為網絡的維護者又應該如何保護好自己，防止受到這種攻擊呢？

網絡環境

我家中接入互聯網的運營商是AS7922 美國 Comcast 公司。

使用的路由器是思科 ISR（集成業務路由器）。與一般企業網絡邊界部署的大型路由器相比，除了吞吐量不同，功能和操作方式上沒有太大區別，運行 Cisco IOS 系統。

此路由器中防火墻功能的配置使用思科的傳統 CBAC（基于上下文的訪問控制）模式，通過 ACL 與 inspect 命令跟蹤返回的數據包相結合來實現包過濾防火墻和有狀態防火墻。

Comcast 使用 DHCP 給我的路由器分配了 1 個 IPv4 地址，使用 DHCPv6-PD （前綴下發）分配了一個/60 大小的前綴，這樣我最多有 16 個 /64（這是 IPv6 環境下通行的網絡前綴長度，適合給一個 VLAN分配）大小的 IPv6 子網。

我為家中的設備配置了可以通過IPv4和 IPv6 訪問的 DNS 服務器，這些 DNS 服務器都可以正常返回一個域名的 A 以及AAAA 記錄。

攻擊記錄

2018年9 月 20 日，在完善家中路由器的防火墻設置時，我發現了三條不尋常的日志（本文撰寫時又發現三條）。

以第一條日志為例，解釋一下各個字段的含義（見表1）：

圖1 攻擊記錄截圖

表1 相關字段的含義

日志分析

時間

幾次掃描分別發生在：下午 1∶51，凌晨 1∶00，下午 1∶28，凌晨 4∶47，下午 4∶44，凌晨 4∶19。這些時段我是不會活躍地使用家中網絡的，可以排除與我的操作直接相關的實時在線掃描。即這種掃描不是request-response 形式的，而是一種收集與掃描分開的形式。

源地址

這幾次掃描都來自同一個 /64 前綴——2600∶1F18∶6058∶A200∶∶/64，此前綴屬于 AS14618 亞馬遜 AWS EC2 云主機。

亞馬遜云計算的 IPv6 分配策略如下：AWS VPC 會被分配一個 /56，其中有 256個 /64 的子網可供分配。地址的來源是亞馬遜自己的全球單播地址池。

根據以上分配策略，很容易得出結論，這六次掃描是同一個 AWS 賬號所為。

從這幾個源地址的接口標識符（IID，即后 64 位）來看，這些主機的角色并不是服務器，而是一些使用 SLAAC 獲得前綴自行分配地址的客戶機。因為服務器的地址通常是方便人類閱讀和配置，最起碼也是有一定規律的形式。

目的地址

除了第 1 條日志條目中的目的地址是手工分配的以外（沒有使用 SLAAC，并且此地址對應的設備并不是一直在線）。后面第 2-6 條日志的目的地址所在的子網均開啟了路由器宣告（RA），所以主機會使用 SLAAC 及其隱私擴展生成自己的全球單播 IPv6 地址。

綜上所述，可以排除一直開著的設備call home 觸發掃描的可能性。

通常 Windows 和 Mac 都會生成兩個地址，一個叫“ 臨時 IPv6 地址（Temporary IPv6 address ）”，默認用于對外發起連接，一個叫“公有 IPv6 地址（Public IPv6 address )”。

臨時地址的接口標識符（即后 64 位）是隨機生成的，會在較短的時間內過期，除非應用程序要求使用公有IPv6地址，否則系統默認優先使用臨時地址對外發起連接。

到了 IPv6 的時代，IPv6 一個子網的大小就是整個 IPv4 地址數量的 232倍，非常不利于攻擊者掃描目標網絡。通常我們認為在IPv6上對網段的掃描不會發生，起碼對于了解 IPv6 的攻擊者來說不會選擇這樣浪費時間。

公有 IPv6 地址的生命周期有兩種，分別為有效期（Valid Lifetime，30天），優選期（Preferred Lifetime，7天）。應用程序可以向操作系統請求選擇使用相對穩定的公有 IPv6 地址。地址選擇的算法詳見 RFC 6724。

臨時地址的使用不僅能降低此類掃描的風險，還能在如今廣告提供商無下限地跟蹤用戶的環境下盡可能在地址層面保護用戶的隱私。

目的端口

目的端口都是 80，這也是我一眼能識別出這是掃描而不是正常訪問的依據，因為我沒有在 80 端口上提供服務。攻擊者試圖連接 TCP 80 端口（即 HTTP 服務使用的端口）的行為目前也沒有合適的解釋。

由于我的防火墻對 ICMPv6 是放行且不寫入日志的，所以攻擊者是否先嘗試ping 幾個地址無從得知。

以上對日志的分析，引出了一個新問題：

我家內網的IPv6 地址是如何被攻擊者所知曉的？

前面已經講到，針對 IPv6 的網絡掃描，不可能是對一個 /64 內的所有地址進行掃描，一定是針對單獨 IPv6 地址的掃描，地址的獲得既可以通過猜測，也可以通過采集。

在這個案例中，通過日志中有限的幾個條目，以及目的地址處在兩個不同的/64 子網，完全可以排除攻擊者使用掃描整個網絡這種愚蠢的方法。

通過對目的地址的分析，可以排除攻擊者猜測一些常見的諸如——“∶∶”, “∶∶1”,“∶∶123”, “∶∶abc”, “∶192∶168∶1∶1”形式作為接口標識（IID，后 64 位）的 IPv6 地址。

網絡中一個使用過/使用中的 GUA IPv6 地址可能出現的位置有：

1.本機的網絡接口配置

2.本地應用程序日志

3.本機在 DNS 中的動態條目

4.應用層協議的 Payload 中嵌入了IPv6 地址

5.路由器/多層交換機和同網段其他機器的 ND 緩存

6.DNS 服務器查詢日志

·DNS 提供商自身的日志

·網絡中對 DNS 請求的嗅探和劫持

7. NetFlow 導出日志

8.Web 服務器和應用服務器訪問日志

·所訪問網站的日志泄露

a.一般網站

b.IPv6 測試網站（志愿加入提供服務，不排除有惡意設置的服務器）

·CDN 提供商的訪問日志泄露

9.代理服務器訪問日志

·未授權 WPAD 代理配置下發服務造成客戶端使用攻擊者設置的代理服務器

·透明代理和 HTTP 劫持代理的日志泄露

10.交換機端口鏡像流量

·合法或非法嗅探用戶流量

（以上十條是我個人的總結，有疏忽和遺漏的地方歡迎大家指正。）

由于 IPv6 端到端的特性，任何一個數據包的地址在其整個生命流程中都不大可能被改變。即使有 NPTv6 這種無狀態修改前綴的設備在使用，TCP、UDP、ICMP等不依賴 IPv6 地址進行認證的協議還是不會給攻擊者造成任何不便。

所以上述任何一個位置如果被攻擊者控制，均會造成客戶端 IPv6 地址落入攻擊者手中，使其可以為進一步內網滲透做準備。

目前分析較為可能的是某 Web 服務器上的日志被有意無意濫用，造成客戶端 IPv6 地址落到攻擊者手中，攻擊者收集了一定量的數據后開始對這些地址進行了掃描。

發現基礎設施的不足之處

1.設備的 IPv6 地址沒有跟蹤和溯源機制，事后無從追查當時使用某個目的地址的機器是哪一臺。

2.訪問控制列表中的放行策略也許還是不夠嚴格，有沒有漏網之魚無從得知。

3.對每一個自內而外發起的連接/會話沒有跟蹤，網絡上發生了什么，哪些前綴、哪些協議、哪些 TCP/UDP 端口比其他的要更活躍，流量都去哪里了……這些基礎網絡情報都沒有收集，出現問題沒有深入調查的條件。

4.設備（此案例中是路由器）的日志僅僅保存在設備內存當中，一旦斷電重啟，本文可能不會出現在讀者面前。

如何防范此類攻擊

第一，完善企業網絡安全制度。如果IPv4 的安全制度已經成熟可靠，則要盡快將其應用到IPv6 環境下。如果 IPv4 下的安全制度缺失，那么在 IPv6 的推廣部署過程中，企業沒有歷史包袱，就有機會站在更高的起點上，借鑒行業內領先的網絡安全策略和實施方案，建立健全企業網絡安全規范制度。

第二，理解并配置 IPv6 防火墻。理解 IPv6 包結構與 IPv4 包的本質不同，即 IPv6 包頭是類似鏈表的結構，而IPv4 包頭是層層嵌套結構。使用白名單模式配置防火墻，只放行已知合法的流量及其返回的數據包。部署支持IPv6 的IDS/IPS。

第三，主機的防火墻也應該打開，只放行本機對外必需的服務。萬物互聯的時代，應用和環境千差萬別，僅依賴網絡設備上的防護是遠遠不夠的。安全是網絡和應用共同協作的結果。

第四，企業環境中應使用有狀態DHCPv6 為客戶端分配地址，但是不應該讓客戶端長時間采用同一個地址，而是應該設置較短的地址生命周期，并采用好的隨機算法生成客戶端后綴。要完成國家對 IPv6 地址溯源的需求，只需要保留好 DHCPv6服務器日志，并定期從接入交換機、AP 上采集 MAC 地址與 IPv6地址的對應關系即可。切不可圖省事，為客戶端分配長久不變的地址。這種做法，為自己的網絡帶來安全隱患的同時，徹底毀掉了 IPv6 為終端客戶帶來的一點隱私保護措施。

觀察

宋崟川先生遭遇對內網主機IP地址的精準掃描，雖然是“第一次發現”，但是絕對不能說這種情況是 “第一次出現”，因為很可能以前出現了很多次，但是一直沒有被發現。只是本次比較偶然被發現。

同時，這種情況不可能僅僅發生在美國的IPv6網絡中，中國的IPv6網絡有沒有遭遇到這種精準掃描？在沒有確鑿證據的前提下，我們不敢輕易下結論。

兩辦《推進IPv6規模部署行動計劃》文件的基本原則里明確要求 “兩并舉、三同步：發展與安全并舉， 網絡安全要同步規劃、同步建設、同步運行”。因此各單位的IPv6升級工作，網絡安全工作必須也要同步進行，不能只顧一頭。

隨著三大電信運營商和CNGICERNET2開通IPv6網絡接入服務，現在一些企業、教育、IDC和ISP等單位的網絡已經接入了IPv6。但是有幾個問題必須引起足夠的關注：

（1）已接入IPv6的單位，對IPv6網絡安全管理是否給予了足夠的重視？是否采取了針對IPv6網絡安全的必要措施？

（2）升級后的IPv6網絡是否已經妥善配置良好支持IPv6的防火墻、入侵檢測等安全防護設備，可以抵御來自IPv6線路的網絡攻擊？

（3）運維人員的技術能力，是否能滿足IPv6網絡安全建設和突發事件應急處置的需要？

這幾個問題，捫心自問，做到了嗎？

IPv6網絡有很多新的特性，將會產生很多新的網絡安全場景，這些場景與IPv4網絡并不一樣，所需的防護策略也會不一樣。但是，無論IPv6還是IPv4 ，網絡安全在本質上并沒有根本變化，最關鍵的問題是網絡管理者的安全意識、安全措施、應急方案和技術人員的應急處置能力，這些是一切網絡安全運維的核心。